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CHAPTER  1 


INTRODUCTION 


The  Ada  implementation  described  above  was  tested  according  to  the  Ada 
Validation  Procedures  [Pro90]  against  the  Ada  Standard  [Ada83]  using  the 
current  Ada  Coii?)iler  Validation  Capability  (ACVC).  This  Validation  Summary 
Report  (VSR)  gives  an  account  of  the  testing  of  this  Ada  implementation. 

For  any  technical  terms  used  in  this  report,  the  reader  is  referred  to 
[Pro90].  A  detailed  description  of  the  ACVC  may  be  found  in  the  current 
ACVC  User's  Guide  (UG89]. 


1.1  USE  OF  THIS  VALIDATICK  SUMMARY  REPORT 

Consistent  with  the  national  laws  of  the  originating  country,  the  Ada 
Certification  Body  may  make  full  and  free  public  disclosure  of  this  report. 
In  the  United  States,  this  is  pro\'ided  in  accordance  with  the  "Freedom  of 
Information  Act"  (5  U.S.C.  #552).  The  results  of  this  validation  apply 
only  to  the  computers,  operating  systems,  and  compiler  versions  identified 
in  this  report. 

The  organizations  represented  on  the  signature  page  of  this  report  do  not 
represent  or  warrant  that  all  statements  set  forth  in  this  report  are 
accurate  and  conplete,  or  that  the  subject  inplementation  has  no 
nonconformities  to  the  Ada  Standard  other  than  those  presented.  Copies  of 
this  report  are  available  to  the  public  from  the  AVF  v^ich  performed  this 
validation  or  from: 

National  Technical  Information  Service 
5285  Port  Royal  Road 
Springfield  VA  22161 


Questions  regarding  this  report  or  the  validation  test  results  should  be 
directed  to  the  AVF  which  performed  this  validation  or  to: 

Ada  Validation  Organization 
Institute  for  Defense  Analyses 
1801  North  Beauregard  Street 
Alexandria  VA  22311 
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1 . 2  REFERENCES 


{ Ada03 1  Reference  Manual  Tor  TEe  Ada  Rrograinming  Language/ 
ANSI/MIL-STD-1815A,  February  1983  and  ISO  8652-1907. 


(Pro90)  Acta  Conpiler  Validation  {Procedures/  Version  2.1/  Ada  Joint  Program 
Office/  August/  1990. 


[1X3891  S3a  Compiler  Validation  Capability  UiePT  Cuide'/  21  Juno  1989. 


1.3  ACVC  TEST  CLASSES 

Compliance  of  Ada  implementations  is  tested  by  means  of  the  ACVC.  The  ACVC 
contains  a  collection  of  test  programs  structured  into  six  test  classes: 

A,  B/  C,  D.  E,  and  L.  The  first  letter  of  a  test  name  Identifies  the  class 
to  which  it  belongs.  Class  A/  C.  0.  and  E  tests  are  executable.  Class  B 
and  class  L  tests  are  expected  to  produce  errors  at  compile  time  and  link 
time,  respectively. 

The  executable  tests  are  written  in  .n  self-checking  manner  and  produce  a 
PASSED,  FAILED/  or  NOT  APPLICABLE  message  indicating  the  result  v^en  they 
are  executed.  Three  Ada  library  units,  the  packages  REPORT  and  SPPRT13/ 
and  the  procedure  CHECK  FILE  are  used  for  this  purpose.  The  package  REPORT 
also  provides  a  set  of  Identity  functions  used  to  defeat  some  compiler 
optimizations  allowed  by  the  Ada  Standard  that  would  circumvent  a  test 
objective.  The  package  SPPRT13  is  used  ley  many  tests  for  Chapter  13  of  the 
Ada  Standard.  The  procedure  CHECK  FILE  is  used  to  check  the  contents  of 
text  files-  written  by  some  of  the  ?lass  C  tests  for  Chapter  14  of  the  Ada 
Standard.  The  operation  of  REPORT  and  CHECK^FILE  is  checked  by  a  set  of 
executable  tests.  If  these  units  are  not  operating  correctly,  validation 
testing  is  discontinued. 

Class  5  tests  check  that  a  compiler  detects  illegal  language  usage.  Class 
B  tests  are  not  executable.  Each  test  in  this  class  is  conpiled  and  the 
resulting  con^ilation  listing  is  examined  to  verify  that  all  violations  of 
the  Ada  Standard  are  detected.  Some  of  the  class  B  tests  contain  legal  Ada 
code  which  must  not  be  flagged  illega:.  by  the  compiler.  This  behavior  is 
also  verified. 

Class  L  tests  check  that  an  Ada  implementation  correctly  detects  violation 
of  the  Ada  Standard  involving  multiple,  separately  compiled  units.  Errors 
are  expected  at  link  time,  and  execution  is  attempted. 

In  some  tests  of  the  ACVC,  certain  macro  strings  have  to  be  replaced  by 
implementation-specific  values  —  for  example,  the  largest  integer.  A  list 
of  the  values  used  for  this  implementation  is  provided  in  Appendix  A.  In 
addition  to  these  anticipated  test  modifications,  additional  changes  may  be 
required  to  remove  unforeseen  conflicts  between  the  tests  and 
implementation-dependent  characteristics.  The  modifications  required  for 
this  implementation  are  described  in  section  2.3. 

Best  Avallahl<a 
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for  each  Ada  impltmentation,  a  cuatomizod  test  suit*  is  productd  by  tht 
Avr.  This  customization  consists  of  making  the  modifications  described  in 
the  preceding  paragraph,  removing  withdrawn  tests  (see  section  2.1)  and, 
possibly  some  Inapplicable  tests  (see  Section  2.2  and  [UG89]). 

In  order  to  pass  an  AG/C  an  Ada  imnlementation  must  process  each  test  of 
the  customized  test  suite  according  to  the  Ada  Standard. 


1.4  DEFINITION  OF  TERMS 


Ada  Compiler  The  software  and  any  needed  hardware  that  have  to  be  added 
to  a  given  host  and  target  computer  system  to  allow  . 
transformation  of  Ada  programs  into  executable  form  and 
execution  thereof. 

Ada  Compiler  The  means  for  testing  compliance  of  Ada  implementations. 
Validation  consisting  of  the  test  suite,  the  support  programs,  the  ACVC 
Capability  user's  guide  and  the  template  for  the  validation  summary 

(ACVC)  report. 

Ada  An  Ada  conpiler  with  its  host  computer  system  and  its 

Implementation  target  compter  system. 

Ada  Joint  The  part  of  the  certification  body  which  provides  policy  and 

Program  guidance  for  the  Ada  certification  system. 

Office  (AJPO) 

Ada  The  part  of  the  certification  body  which  carries  out  the 

Validation  procedures  required  to  establish  the  conpliance  of  an  Ada 
Facility  (AVF)  implementation. 

Ada  The  part  of  the  certification  body  that  provides  technical 

Validation  guidance  for  operations  of  the  Ada  certification  system. 

Organization 
(AVO) 

Compliance  of  The.  ability  of  the  implementation  to  pass  an  ACVC  version, 
an  Ada. 

Implementation 

Computer  A  functional  unit,  consisting  of  one  or  more  computers  and 

System  associated  software,  that  uses  common  storage  for  all  or 

part  of  a  program  .and  also  for  all  or  part  of  the  data 
necessary  for  the  execution  of  the  program;  executes 
user-written  or  user-designated  programs;  performs 
user-designated  data  manipulation,  including  arithmetic 
operations  and  logic  operations;  and  that  can  execute 
programs  that  modify  themselves  during  execution.  A 
conputer  system  may  be  a  stand-alone  unit  or  may  consist  of 
several  inter-connected  units. 
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Confonnity 


Customer 


Declaration  of 
Conformance 


Host  Computer 
System 

Inapplicable 

test 

ISO 

LRM 


Operating 

System 


Target 

Computer 

System 

Validated  Ada 
Compiler 

Validated  Ada 
Impleirentation 

Validation 


Withdrawn 

test 


Fulfillment  by  a  product,  process  or  service  of  all 
requirements  specified. 

An  individual  or  corporate  entity  vdio  enters  into  an 
agreement  with  an  AVF  vdiich  specifies  the  terms  and 
conditions  for  AVF  services  (of  any  kind)  to  be  performed. 

A  formal  statement  from  a  customer  assuring  that  conformity 
is  realized  or  attainable  on  the  Ada  implementation  for 
vdiich  validation  status  is  realized. 

A  conputer  system  vdierc  Ada  source  programs  are  transformed 
into  executable  form. 

A  test  that  contains  one  or  more  test  objectives  found  to  be  - 
irrelevant  for  the  given  Ada  inplementation. 

International  Organization  for  Standardization. 

The  Ada  standard,  or  Language  Reference  Manual,  pxdslished  as 
ANSI/MIL-STD-1815A-1983  and  ISO  8652-1987.  Citations  from 
the  LRM  taJce  the  form  "<section>.<subsection>:<paragraph>." 

Software  that  controls  the  execution  of  programs  and  that 
provides  services  such  as  resource  allocation,  scheduling, 
input/output  control,  and  data  management.  Usually, 
operating  systems  are  predominantly  software,  but  partial  or 
complete  hardware  implementations  are  possible. 

A  computer  system  where  the  executable  form  of  Ada  programs 
are  executed. 


The  compiler  of  a  validated  Ada  implementation. 


An  Ada  implementation  that  has  been  validated  successfully 
either  by  AVF  testing  or  by  registration  [Pro90]. 

The  process  of  checking  the  confonnity  of  an  Ada  compiler  to 
the  Ada  programming  language  and  of  issuing  a  certificate 
for  this  implementation. 

A  test  foiind  to  be  incorrect  and  not  used  in  conformity 
testing.  A  test  may  be  incorrect  because  it  has  an  invalid 
test  objective,  fails  to  meet  its  test  objective,  or 
contains  erroneous  or  illegal  use  of  the  Ada  programming 
language . 
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IMPLEMENTATION  DEPENDENCIES 


2.1  WITHDRAWN  TESTS 

The  following  tests  have  been  withdrawn  by  the  AVD.  The  rationale  for 
withdrawing  each  test  is  available  from  either  the  AVO  or  the  AVF.  The 
publication  date  for  this  list  of  withdrawn  tests  is  12  October  1990. 


E28005C 

B28006C 

C34006D 

B41308B 

C43004A 

C45114A 

C45346A 

C45612B 

C45651A 

C46022A 

B49008A 

A74006A 

C74308A 

B8i022B 

B83022H 

B83025B 

B83025D 

B83026B 

B85001L 

C83026A 

C83041A 

C97116A 

C98003B 

BA2011A 

CB7001A 

CB7001B 

CB7004A 

CC1223A 

BC1226A 

CC1226B 

BC3009B 

BD1B02B 

BD1B06A 

AD1B08A 

BD2AC2A 

CD2A21E 

CD2A23E 

CD2A32A 

CD2A41A 

CD2A41E 

CD2A87A 

CD2B15C 

BD3006A 

BD4008A 

CD4022A 

CD4022D 

CD4024B 

CD4024C 

CD4024D 

CD4031A 

CD4051D 

CD5111A 

CD7004C 

ED7005D 

CD7005E 

AD7006A 

CD7006E 

AD7201A 

AD7201E 

CD7204B 

BD8002A 

BD8004C 

CD9005A 

CD9005B 

CDA201E 

CE2107I 

CE2117A 

CE2117B 

CE2119B 

CE2205B 

CE2405A 

CE3111C 

CE3118A 

CE3411B 

CE3412B 

CE3607B 

CE3607C 

CE3607D 

CE3812A 

CE3814A 

CE3902B 

2.2  INAPPLICABLE  TESTS 

A  test  is  inapplicable  if  it  contains  test  objectives  ^ich  are  irrelevant 
for  a  given  Ada  iirplementation.  Reasons  for  a  test's  inapplicability  may 
be  supported  by  documents  issued  by  ISO  and  the  AJPO  known  as  Ada 
Commentaries  and  commonly  referenced  in  the  format  Al-ddddd.  For  this 
implementation,  the  following  tests  were  determined  to  be  inapplicable  for 
the  reasons  indicated;  references  to  Ada  Commentaries  are  included  as 
appropriate . 
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IMPLEMENTATION  DEPENDENCIES 


The  following  201  tests  have  floating-point  type  declarations  requiring 
more  digits  than  SYSTEM. MAX_DIGITS: 


C24113L..Y  (14  tests) 
C35706L..y  (14  tests) 
C35708L..Y  (14  tests) 
C45241L..Y  (14  tests) 
C45421L..Y  (14  tests) 
C45524L..Z  (15  tests) 
C45641L..Y  (14  tests) 


C35705L..Y  (14  tests) 
C35707L..Y  (14  tests) 
C35802L..Z  (15  tests) 
C45321L..Y  (14  tests) 
C45521L..Z  (15  tests) 
C45621L..Z  (15  tests) 
C46012L..Z  (15  tests) 


The  following  21  tests  check  for  the  predefined  type  SHORT_INTEGER: 


C35404B 

B36105C 

C45231B 

C45304B 

C45411B 

C45412B 

C45502B 

C45503B 

C45504B 

C45504E 

C45611B 

C45613B 

C45614B 

C45631B 

C45632B 

B52004E 

C55B07B 

B55B09D 

B86001V 

C86006D 

CD7101E 


C35404D,  C45231D,  B86001X,  C86006E,  and  CD7101G  check  for  a  predefined 
integer  type  with  a  name  other  than  INTEGER,  L(»K3_INTEGER,  or 
SHORT  INTEGER. 


C35702A,  C35713B,  C45423B,  B86001T,  and  C86006H  check  for  the  predefined 
type  SHORT_FLOAT. 

C35702B,  C35713C,  B86001U,  and  C86006G  check  for  the  predefined  type 
LONG_FLOAT. 

C35713D  and  B86001Z  check  for  a  predefined  floating-point  type  with  a 
name  other  than  FLOAT,  LC»^G_FLCIAT,  or  SHORT_FLQAT. 

A35801E  checks  that  FLOAT' FIRST. .FLOAT' LAST  may  be  used  as  a  range 
constraint  in  a  floating-point  type  declaration;  for  this 
implementation,  that  range  exceeds  the  range  of  safe  numbers  of  the 
largest  predefined  floating-point  type  and  must  be  rejected.  (See 
section  2.3.) 


C45624A  checks  that  the  proper  exception  is  raised  if  MACHINE_OVERFLCWS 
is  FALSE  for  floating  point  types  with  digits  5.  For  this 
implementation,  MACHINEjOVERFLOMS  is  TRUE. 

C45624B  checks  that  the  proper  exception  is  raised  if  MACHlNE_OVERFLOWS 
is  FALSE  for  floating  point  types  with  digits  6.  For  this 
implementation,  MACHINE_OVERFLOWS  is  TRUE. 

D56001B  uses  65  levels  of  block  nesting  which  exceeds  the  capacity  of 
the  compiler. 

D64005G  uses  17  levels  of  recursive  procedure  calls  nesting  which 
exceeds  the  capacity  of  the  compiler. 
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IMPLEMENTATION  DEPENDENCIES 


B86001Y  checks  for  a  predefined  fixed-point  type  other  than  DURATIC^. 

C92005B  includes  a  conversion  of  the  ' STORAGE_SIZE  value  for  a  task  to 
type  INTEGER;  for  this  implementation,  that  value  exceeds  INTEGER'LAST 
cind  the  conversion  raises  CONSTPAlMT_ERROR,  idiich  terminates  the  test. 

( See  section  2.3.) 

LA3004A,  LA3004B,  EA3004C,  EA3004D,  CA3004E,  and  CA3004F  check  for 
pragma  INLINE  for  procedures  and  functions. 

CD1009C  uses  a  representation  clause  specifying  a  non-default  size  for  a 
floating-point  type. 

BD2A85A  and  BD2A85B  expect  that  sices  of  2  and  3,  respectively,  will  be 
rejected  as  too  small  for  the  sics  of  an  access  type  when  given  in  a 
length  clause;  this  in^lementaticn  creats  access  values  as  offsets  and 
so  accepts  the  length  clauses.  (See  section  2.3.) 


The  following  45  tests  contain  address  clauses.  This  implementation 
does  not  support  address  clauses.  (See  section  2.3.) 


CD5003A..I  (9  tests) 

CD501i.A 

CX»5011C 

CD5011E 

CD5011G 

CD5011I 

CD5011K 

CD5011!! 

CD5011Q 

CD5011S 

CDSOld.-.. 

.S  ;2  tests)  CD5012E..F 

(2  tests 

CD5012I 

CD50i;:- 

CD5013A 

CD5013C 

CDSOiZS 

CD5013G 

CD5C13I 

CDSOlfS 

a»5013M 

CD5013O 

CDSOi^;-. 

CD5014C 

CD5014E 

CD501.C 

CD5014I 

CD5014K 

CDSOi.r 

CD5014O 

CD5014T 

CD501  /■; 

CD5014X. .Z 

(3  tests! 

BD8001A,  BD8003A,  BD8004A. 
insertions. 

.B  (2  -.3C 

C3 : ,  and  AD8011A  use  machine  code 

AE2101H,  EE2401D,  and  EE2401G  use  : 

nscantiations  of  package  DIRECT_IO 

with  unconstrained  array  types  and  .ecord  types  with  discriminants 
without  defaults.  These  instanceccions  are  rejected  by  this  compiler. 

The  tests  listed  in  the  following  -.abie  are  not  applicedole  because  the 
given  file  operations  are  supporccc  for  the  given  combination  of  mode 
and  file  access  method. 


Test 

File  Operation 

■’cde 

File  Access  Method 

CE2102D 

CREATE 

d'  ~ILE 

SEQUENTIAL  10 

CE2102E 

CREATE 

d;f  riLE 

SEQUENTIAL  10 

CE2102F 

CREATE 

FILE 

DIRECT  10 

CE2102I 

CREATE 

Id  FILE 

DIRECT  10 

CE2102J 

CREATE 

I'JT  FILE 

DIRECT  10 

CE2102N 

OPEN 

Id  'ILE 

SEQUENTIAL  10 

CE2102O 

RESET 

file 

SEQUENTIAL  10 

inPLEMENT^TZON  DEPENDENCIES 


CE2102P 

OPEN 

OUT  FILE 

SEQUENTIAL  10 

CE2102Q 

RESET 

OtnT FILE 

SEQUENTIAL  10 

CE2102R 

OPEN 

INCUT  FILE 

DIRECT  10 

CE2102S 

RESET 

INOUT  FILE 

DIRECT  10 

CE2102T 

OPEN 

IN  FILE 

DIRECT  10 

CE2102U 

RESET 

IN  FILE 

DIRECT  10 

CE2102V 

OPEN 

OUT  FILE 

DIRECT  10 

CE2102W 

RESET 

OUT  FILE 

DIRECT_IO 

CE3102E 

CREATE 

IN__FILE 

’IEXI_10 

CE3102F 

RESET 

Any  Node 

TEXT_IO 

CE3102G 

DELETE 

TEXT__IO 

CE3102I 

CREATE 

OUT  FILE 

TEXT_IO 

CE3102J 

OPEN 

IN  FILE 

TE3n'_IO 

CE3102K 

OPEN 

OUT  FILE 

TEXT_IO 

The  following  16  tests  check  operations  on  sequential,  direct,  and  text 
files  when  multiple  internal  files  are  associated  xd.th  the  same  external 
file  and  one  or  more  are  open  for  writing;  USEJEREOR  is  raised  when  this 
association  is  atteiqpted. 


CE2107B..E  CE2107G. .H  CE2107L  CD2110B  CE2110D 

CE2111D  CE2111H  CE3111B  CE3111D..E  CE3114B 

CE3115A 

CE2102K  and  CE2401B  check  operations  on  files  with  an  element  type  of 
the  access  class  ;  this  implementation  does  not  permit  I/O  of  access 
values,  and  so  raises  USE_ERROR  on  the  attempt  to  create  a  file. 

CE2203A  checks  that  WRITE  raises  USE_ERROR  if  the  capacity’-  of  toe 
external  file  is  exceeded  for  SEQUQmAL_IO.  This  implementation  does 
not  restrict  file  capacity. 

CE2401B  checks  READ,  WRITE,  SET  INDEX,  INDEX,  SIZE,  and  QJD_OF  FILE  for 
direct  files  with  ELEMEWT_TYPES~boolean,  access,  and  enumerated. 

C:e2403A  checks  that  WRITE  raises  USE_ERROR  if  the  capacity  of  the 
exteiTuQ  file  is  exceeded  for  DIRECT_IO.  Ihis  iaplementation  does  not 
restrict  file  capacity. 

CE3304A  checks  that  USE_ERROR  is  raised  if  a  call  to  SET  LINE  LENGTH  or 
SET_PAGE  LENGTH  specifies  a  value  that  is  inappropriate  for  tEe  external 
file.  tEIs  implementation  does  not  have  inappropriate  values  for  either 
line  length  or  page  length. 

CE3413B  checks  that  PAGE  raises  LAYDUT_ERROR  when  the  value  of  the  page 
rnanber  exceeds  COUNT' LAST.  For  this  implementation,  the  value  of 
COUNT' LAST  is  greater  than  150000  making  the  checking  of  this  objective 
impractical . 
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2.3  “  TEST  MODIFICATIONS 

Modifications  (see  section  1.3)  veL'e  required  for  111  tests. 

The  following  tests  were  split  into  two  or  more  tests  because  this 
implementation  did  not  report  the  violations  of  the  Ada  Standard  in  the  way 
expected  by  the  original  tests. 


B22003A 

B22003B 

B22004A 

B22004B 

B22004C 

B23002A 

B23004A 

B23004B 

B24001A 

B24001B 

B24001C 

B24005A  ^ 

B24005B 

B24007A 

B24009A 

B24204B 

B24204C 

B24204D 

B25002B 

B26001A 

B26002A 

B26005A 

B28003A 

B28003C 

B29001A 

B2A003B 

B2A003C 

B2A003D 

B2A007A 

B32103A 

B33201B 

B33202B 

B33203B 

B33301A 

B33301B 

B35101A 

B36002A 

B37106A 

B37203A 

B37307B 

B38003A 

B38003B 

B38009A 

B38009B 

B4120iA 

B44001A 

B44004A 

B44004B 

B44004C 

B44004D 

B44004E 

B45205A 

B48002A 

B48002D 

B53003A 

B55A01A 

B56001A 

B63001A 

B63001B 

B64001B 

B64006A 

B67001A 

B67001B 

B67001C 

B67001D 

B67001H 

B71001A 

B71001G 

B71001M 

B74003A 

B74307B 

B83E01C 

B83E01D 

B83E01E 

B91001F 

B91001H 

B91003E 

B95001D 

B95003A 

B95004A 

B95006A 

B95007B 

B95079A 

BAIOOIB 

BB3005A 

BC1109A 

BC1109B 

BC1109C 

BC1109D 

BC1303F 

BC2001D 

BE2210A 

BC2001E 

BE2413A 

BC3C03A 

B5100L'-. 

BC3003B 

BC3005B 

BC3013A 

A35801E  was  graded  inapplicable  by  Evaluation  Modification  as  directed 
by  the  AVO.  The  compiler  rejeccs'the  use  of  the  range 
FLOAT' FIRST. .FLOAT' LAST  as  the  Tange  constraint  of  a  floating-point 
type  declaration  because  the  lie  outside  of  the  range  of  safe 

numbers  (cf.  LRM  3.5.7:12), 

BD2A85A  and  BD2A85B  were  gradec  inapplicable  by  Evaluation 
Modification  as  directed  by  *he  AVO.  These  tests  each  contain  a  size 
length  clause  for  an  access  cyxe  that  is  expected  to  he  rejected  by 
the  compiler  because  of  the  small  value  that  is  specified  for  the 
size.  However,  this  implemenccxion  treats  access  values  as  offsets 
-into  the  collection  (see  Appendix  C,  section  4.6),  and  thus  accepts 
these  clauses. 

C45232A  was  passed  by  Test  Modification  as  directed  by  the  AVO.  This  test 
contains  the  expression  "INTEGER' L.^T  >  SMALL_INT' BASE 'LAST"  at  lines  131 
and  169;  the  test  does  not  anticipace  that  if  the  condition  is  false,  the 
implicit  conversion  of  the  right  operand  to  type  INTEGER  may  raise  an 
exception.  This  inplementation  selects  type  LCM;_INTEGER  for  the  base  type 
of  SMALL_INT,  and  so  raises  an  exception.  The  test  was  modified  by 
inserting  '  FALSE  THEN  — '  immediar.-eiv  after  'IF'  in  both  lines,  vrtiich  • 
avoids  the  exeption  and  accurately  reflects  the  actual  condition;  this  ' 
modified  version  was  passed. 

A99007A  was  graded  passed  by  Test  [lodification  as  directed  by  the  AVO. 

This  test  assigns  a  taslt's  'STORAGE_SIZE  value  to  an  INTEGER  object;  for 
this  implementation  that  assignment  raises  an  exception,  because  the  value 
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is  greater  than  INTEGER' LAST.  The  test  was  modified  by  re-defining  type 
"INTEGER"  at  line  13  with  "TYPE  INTEGER  IS  RANSGE  0.  .MAX_INT;";  the 
modified  test  was  passed. 

C92005B  was  graded  inapplicable  by  Evaluation  Modification  as  directed  by 
the  AVO.  This  in^lementation's  'STORACS  SIZE  value  for  tasks  is  2**32, 
unless  another  value  has  been  specified  By  a  length  clause.  In  this  test 
no  length  clause  is  present,  and  the  conversion  of  attribute's  value  to 
type  INTEGER  raises  CONSTRAINT_ERROR;  there  is  no  handler  for  this 
exception  in  the  test,  and  so  execution  terminates. 

CD1C04E  was  graded  passed  by  Evaluation  Modification  as  directed  by  the 
AVO.  This  test  checks  that  a  record  representation  clause  for  a  derived 
type  dtermines  the  values  of  the  'POSITIcai,  'FIRST  BIT,  and  'LAST_BIT 
attributes  of  components  of  objects  of  the  type,  v^ien  the  parent  type  has 
been  given  a  different  representation.  For  this  implementation, 

SYSTEM.  STORAGEJUNIT  ■  1,  and  thtis  'FIRST_BIT  always  returns  0  and  the  check 
for  inequality  fails.  The  AVO  ruled  that  this  was  acceptable  behavior;  the 
test  was  graded  passed  because  all  other  checks  were  applicable  and  passed. 

CC1220A  was  graded  passed  by  Evaluation  Modification  as  directed  by  the 
AVO.  This  test  evaluates  the  address  of  the  same  generic  formal  object  of 
mode  in  at  lines  35  and  66;  it  expects  that  address  to  be  the  same.  The 
issues  of  v4iat  the  address  of  a  constant  is,  and  whether  it  must  remain 
constant  over  the  life  of  the  object  are  unclear;  the  AVO  ruled  that  the 
implementation's  behavior  is  acceptable  pending  resolution  of  AI-00203  by 
the  ARG.  The  test  was  graded  as  passed  even  though  the  test  reported 
"FAILED",  given  that  the  only  call  to  Report. Failed  occurred  for  the 
controversial  check  at  line  66,  which  output  the  message  "IMPROPER  VALUE 
FOR  'ADDRESS". 

CD2A83A,  CD2A84A,  CD2A84E,  CD2A84I,  CD2B11A,  and  CD2B11B  were  graded  passed 
by  Test  Modification  as  directed  by  the  AVO.  These  tests  check  the  use  of 
access  types  whose  type  size  and  collection  size  have  been  specified  with 
length  clauses.  In  order  to  accommodate  this  implementation's  unusual 
interpretation  of  these  values  (see  the  discussion  above  re  BD2A85A  and 
BD2A85B),  the  specified  vedues  were  modified  as  follows  and  the  modified 
tests  were  passed: 

for  CD2A84A,  CD2A84E,  and  CD2A84I,  changed  were: 

constant  BASIC_SIZE's  value,  from  8  to  10,  11,  and  10,  respectively; 
constant  CX)LL_SIZE'3  value,  by  inserting  the  multiplier  '  *  8' 

(which  essentially  compensates  for  SYSTEM. STORAGEJUNIT  being  1  vs.  8) 

for  CD2A83A,  constant  CX7LL_SIZE's  value  was  also  changed  as  above;  and 

for  CD2B11A  and  CD2B11B,  constant  BASIC_SIZE's  value  was  changed  by 

inserting  '  *  8'  (in  these  two  tests,  BASIC_SI2E  is  the  collection  size) 

The  following  45  tests  were  graded  inapplicable  by  Evaluation  Modification 
as  directed  by  the  AVO.  These  tests  check  for  support  of  address  clauses. 
This  implementation  "uses  a  memory-protection  scheme  that  prohibits 
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arbitrary  address  calculations  including  the  use 

of  an  address 

literal. 

. . .  Consequently,  address 

clauses  Are 

not  supported.”  (Appendix  C,  section 

6.1] 

CO5003a:.X  (9  tests) 

CD5011A 

CD5011C 

CD5011E 

CD5011G 

CD5011X 

CD5011K 

CD5011M 

CD5011Q 

CD5011S 

CD5012A. .3 

<2  tests) 

CD5012E..f 

(2  tests) 

CD5012I 

CD5012H 

CD5013A 

CD5013C 

CD5013E 

CD5013G 

CD5013I 

CD5013K 

CD5013M 

CD5013O 

CD5014A 

CD5014C 

CD5014E 

CD5014G 

CD5014I 

CD5014K 

CD5014M 

CD5014O 

CD5014T 

CD5014V 

CD5014X..Z 

(3  tests) 

BD4007A,  BD4009A,  and  CD4051C  were  araded  passed  by  Test  Modification  as 
directed  by  the  AVO.  These  tests  use  record  representation  clauses  that 
place  a  field  at  a  0  offset  from  the  start  of  a  record  with  discriminants; 
but  this  implementation  reserves  a  prefix  of  at  least  1  bit  at  the  head  of 
any  record  with  discriminants,  and  so  rejects  the  representation.  The 
tests  were  modified  by  inserting  '1'  to  change  the  offsets  to  10  vice  0; 
the  modified  tests  were  passed. 

For  each  of  the  affected  compor.enc  clauses  (lines  47.. 49  and  56.. 57; 
26,  27  and  29;  and  29  of  the  tests,  respectively)  insert  '1' 
immediately  before  the  'O',  changing  the  offset  value  to  ”10”. 
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3.1  TESTING  ENVIROMENT 

The  Ada  implementation  tested  in  this  validation  effort  is  described 
adequately  by  the  information  given  in  the  initial  pages  of  this  report. 

For  a  point  of  contact  for  technical  information  about  this  Ada 
inf}len»ntation  system,  see: 

David  H.  Bernstein 
3320  Scott  Blvd. 

Santa  Clara  CA  95054 

For  a  point  of  contact  for  sales  information  about  this  Ada  iiiplementation 
system,  see: 


David  H.  Bernstein 
3320  Scott  Blvd. 
Santa  Clara  CA  95054 


Testing  of  this  Ada  inplementation  was  conducted  at  the  customer's  site  by 
a  validation  team  from  the  AVF. 


3.2  SUMMARY  OF  TEST  RESULTS 

An  Ada  Implementation  passes  a  given  ACVC  version  if  it  processes  each  test 
of  the  customized  test  suite  in  accordance  ’.d-th  the  .Ada  Programming 
Leuiguage  Standard,  whether  the  test  is  applicable  or  inapplicable; 
otherwise,  the  Ada  Implementation  fails  the  ACVC  [Pro90]. 

For  all  processed  tests  (inapplicable  and  applicable),  a  resxjdt  was 
obtained  that  conforms  to  the  Ada  Programming  Language  Standard. 
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a)  Total  Number  of  Applicable  Tests  3739 

b)  Total  Number  of  Withdrawn  Tests  81 

c)  Processed  Inapplicable  Tests  149 

d)  Non-Processed  I/O  Tests  0 

e)  Non-Processed  Floating-Point 

Precision  Tests  201 


f)  Total  Number  of  Inapplicable  Tests  350  (c-nl-t-e) 

g)  Total  Number  of  Tests  for  ACVC  1.11  4170  (a+b+f) 


All  I/O  tests  of  the  test  suite  were  processed  because  this  in^lementation 
supports  a  file  system.  The  above  number  of  floating-point  tests  were  not 
processed  because  they  used  floating-point  precision  exceeding  that 
supported  by  the  implementation.  When  this  coitpiler  was  tested,  the  tests 
listed  in  section  2.1  had  been  withdravTi  because  of  test  errors. 


3.3  TEST  EXECUTION 

Version  1.11  of  the  ACVC  comprises  tests.  When  this  compiler  was 
tested,  the  tests  listed  in  section  2.i  had  been  withdrawn  because  of  test 
errors.  The  AVF  determined  that  350  tests  were  inapplicable  to  this 
inplementation.  All  inapplicable  tests  were  processed  during  validation 
testing  except  for  201  executable  tests  that  use  floating-point  precision 
exceeding  that  supported  by  the  irapirtser.cation  In  addition,  the  modified 
tests  mentioned  in  section  2.3  were  also  processed. 

A  magnetic  tape  containing  the  customised  test  suite  (see  section  1.3)  was 
taken  on-site  by  the  validation  team  :or  processing.  The  contents  of  the 
magnetic  tape  were  loaded  directly  onto  the  host  conputer. 


After  the  test  files  were  loaded  onto  the  host  computer,  the  full  set  of 
tests  was  processed  by  the  Ada  implementation.  , 


Testing  was  performed  using  command  scripts  provided  by  the  customer  and 
reviewed  by  the  validation  team.  See  .'.ppendi::  B  for  a  complete  listing  of 
the  processing  options  for  this  implementation.  It  also  indicates  the 
default  options.  The  options  invoked  explicitly  for  validation  testing 
during  this  test  were; 
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Option  I  Switch  Effect 

Create_Subprograin_Specs  -  False  When  a  library  unit  subprogram  body  is  added 

to  the  program  library,  do  not  automatically 
create  a  corresponding  subprogram 
specification. 

Retain__DeltaljConqpatibility  -  False 

~  Do  not  generate  code  conpatible  with  Deltal 

version  of  the  Rational  Enviroment. 

Ignore_Interface_Pragmas  «  True  Causes  pragma  Interface  to  be  ignored. 


Test  output,  conpiler  emd  linker  listings,  euid  job  logs  were  captured  on 
magnetic  tape  and  archived  at  the  AVF.  The  listings  examined  on-site  by 
the  validation  team  were  also  archived. 
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MACRO  PARAMETERS 


This  appendix  contains  the  macro  pararoters  used  for  customizing  the  ACVC.  < 
The  meaning  and  purpose  o£  these  parameters  are  explained  in  [UG89].  The 
parameter  values  are  presented  in  two  tables.  The  first  table  lists  the 
values  that  are  defined  in  terms  of  the  maximum  input-line  length/  which  is 
the  value  for  $MAX_IN_LEN — also  listed  here.  These  values  are  expressed 
here  as  Ada  string  aggregates,  where  "V  represents  the  maximum  input-line 
length. 


Macro  Parameter 


Macro  Value 


$BIG_ID1 

$BIG__ID2 

$BIG_ID3 

$BIG_ID4 


$BIG_INT__LIT 

$BIG__REAL_LIT 

$BIG_STRING1 

$BIG__STRING2 

$BLANKS 


a. .v-1  ->  'A',  V  ->  'V) 

->  'A',  V  ->  '2') 

a... 7/2  ->  'A')  &  '3'  & 
a..V-l-V/2  ->  'A') 

<i.  ,7/2  ->  'A')  &  & 

•'1..V-1-V/2  ->  'Pi') 

':i..V-3  ->  'OM  &  "298" 

{l.,V-5  ->  '0')  &  "690.0" 

&  (1..V/2  ->  'A')  & 
a  (1..V-1-V/2  ->  'A')  &  '1'  & 

(I.. 7-20 


$MAX  LEN  INT  BASED  LITEFwU 

“  "  &  {1..V-5  ->  '0')  &  "11:" 

$MAX  LEN  REAL  BASED  LITERAL 

“  “  "16:''  &  (1..V-7  ■>  '0')  &  "F.E:" 

$MAX_STRING_LITERAL  '"'  S,  (1..V-2  ->  'A')  & 
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The  following  table  lists  all  of  the  other  macro  parameters  and  their 
respective  values . 

Macro  Paranffiter  Macro  Value 


$MAX__IN_LEN 

254 

$ACC__SIZE 

24 

$ALIGNMENT 

1 

$CCXJNT_LAST 

1000000000 

$DEFAULT_MEM_SI ZE 

268435456 

$DEFAULT_STOR__ONIT 

1 

$DEFAULT_SyS_NAME 

RIOOO 

$DELTA  DOC 

1 . 084202172485504434007452800869941711425781250E-19 

$ENTRY_ADDRESS 

ADDRESSl 

$ENTRY_ADDRESS1 

ADDRESS2 

$ENTRY_ADDRESS2 

ADDRESS3 

$FIELD_LAST 

2147483647 

$FILE_'TRMINATOR 

r  f 

$FIXED_NAME 

NO_SUCH_TYPE 

$FLOAT_NAME 

NO_SUCH_TYPE 

$FORM_STRING 

ttn 

$FORM_STRING2 

"CANNOT_RESTRICT_FILE_CAPACITY" 

$CaiEATER  THAN  DURATICW 

5.0E09 

$GREATER  THAN  DURATI<»I  BASE  LAST 

l.OEl? 

$GREATER_THAN__FLQAT 

BASE  LAST 

2.TTE308 

$C3^TER  THAN  FLOAT  SAFE  LAi«3E 

2#lllllllllllllTllllTlllllTllllTlllllllllllllllllllllll.0#E971 

A-2 
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$GREATER_THAN_SHORT_FLOAT_3AFE_LARGE 

,  1.0E308 

$HIGH_PRIORITY  5 

$ILLEGAL_EXTERNAL_FILE_MAfIEl 

BAD  CHARACTERS&<>= 


$  ILLEGAL_EXTERNAL_FILEJ>IAI!E2 

CC:7rAINS_WILDCARDS@ 

$  INAPPROPRIATE_LINE_LEMGTH 

-1 

$  INAPPROPRIATE  PAGE  LE:^JGTH 


$INCLUDE_PRAGMA1 
$INCLUDE_PRAGMA2 
$INTEGER_FIRST 
$INTEGER_LAST 
$  INTEGER_LAST_PLUS_1 
$ INTERFACE_LANGUAGE 
$LESS_THAN_DURATIOM 
$LESS  THAN  DURATION  EA 


-1 

PRAGMA  INCLUDE 
PRAGMA  INCLUDE 
-21^7483647 
21  !'483647 
2ir;33648 
::C_-'24GUAGE 
:209 

GE  7IRST 


("A28006D1.TST") 

("B28006F1.TST”) 


$LINE_TERMINATOR 
$LOW_PRIORITy  0 

$MACHINE  CODE  STATETIEITr 


$MACHINE_CODE_TyPE 

$MANTISSA_DOC 

$MAX_DIGITS 

$MAX_INT 

$MAX_INT_PLUS_1 

$MIN  INT 


i: ’STR.UCTION'  ( ACTICN,  IDLE )  ; 
II'STR.UCTION 


92253-2036854775807 

9223372036854775808 

-9223372036854775808 


MACRO  PARAMETERS 


$NAME  NO_SUCH_TyPE_AVAILABLE 

$NAME_LIST  RIOOO 

$NAME_SPECI FICATIONl 

! VALIDATION  .ACVC_1_11 . RlOOO .  C_LOGS . CHAPTER_E . X2120A 
$NAME_SPECI FICATiaJ2 

1VALIDATIC»J.ACVC_1_11  .RIOOO  .C_LOGS  .CHAPTER_E.X2120B 
$NAME_SPECIFICATICW3 

IVALIDATIOJ.ACVC  1  11. RlOOO. C  LOGS. CHAPTER  E.X3119A 


$NEG_BASED_INT 

16#FFFFFFFFFFFFFFFF# 

$NEW_MEM_SIZE 

268435456 

$NEW_STOR_UNIT 

1 

$NEW_SYS_NAME 

RlOOO 

$PAGE_TERMINATOR 

ASCII. FF 

$RECORD__DEFINITION 

RECORD  NULL;  END  REC 

$RECORD__NAME 

INSTRUCTION 

$TASK_S1ZE 

64 

$TASK_STORAGE_SIZE 

1024 

$TICK 

200.0E-9 

$VARIABLE_ADDRESS 

ADDRESS4 

$VARIABLE_ADDRESS1 

ADDRESS5 

$VARIABLE_ADDRESS2 

ADDRESS6 

$YOUR_PRAaiA 

ENABLE_DEALLOCATICN 
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•  COMPILATION  SYSTEM  OPTIONS 


The  compiler  and  linker  options  o£  this  Ada  implementation,  as  described  in  , 
this  Appendix,  are  provided  by  the  customer.  Unless  specifically  noted 
otherwise,  references  in  this  append!::  are  to  compiler  documentation  and 
not  to  this  report. 

PROCESSOR  SWITCH  TYPE  VALUE 

RlOOO  Cg  .  Asm_Listing  :  Boolean  ;■  False 

— EnaEles  the  creation  of  RlOOO  assembly  code  list  files.  Each  file  is 
--  stored  as  an  attribute  of  the  nsscciated  Ada  unit. 

RlOOO  Cg  .  Check^Compatibility  ;  Boolean  ;■  True 

—  Check  that  subsystem  load  views  are  compatible  with  the  corresponding 

—  spec  views  when  loading  programs. 

Directory  .  Create_Internal  Links  :  Boolean  :•  True 

—  Controls  whether  internal  links  are  created  automatically  v^en  the 

—  visible  parts  of  library  units  are  created.  Internal  links  for  library 

—  units  are  created  in  the  set  of  links  for  the  nearest  enclosing  world. 

—  The  default  is  True.  The  full  switch  name  is 

—  Directory. Create_Internal_Links.  (For  further  information  on  links,  see 
”  the  Key  Concepts  section  of  the  Library  Management  (LM)  Reference 

—  Manual . )  . 

*  Directory  .  Create  Subprogram  Specs  :  Boolean  False 

—  Controls  whether  specificaEicns  for  library-unit  subprograms  are  created 

—  automatically.  The  contents  these  specifications  are  created  the 

—  first  time  the  body  is  successfully  Installed.  The  "with”  clause , for 

—  the  specification  is  derived  frcm  the  "with"  clauses  in  the  body.  Only 

—  those  "with"  clauses  required  to  promote  the  specification  are  Included. 

—  The  default  is  True.  The  full,  -.witch  name  is 
”  Di rectory. Create_Subprogram_Spec3. 

RlOOO  Cg  .  Deltal  Code_View__Comcatibility  :  Boolean  :•  False 

~  Causes  Compilation. Load  and  Cmvc.llake  Code^View  to  create  additional 

—  objects  U.e.,  pre-D__ll_3  0  code  archives )”that  will  be  needed  if  and 
~  only  if  the  resulting  LoaHed  Main  Program  or  Code  View  is  to  be  copied 

—  or  restored  onto  another  RlOOO  'running  a  pre-D  11  3  0  environment 
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—  release;  for  this  switch  to  have  any  effect,  the 

—  Retain_E)eltal_Conpatibility  switch  should  also  be  set. 

RlOOO  Cg  .  EleJa  Order_Listing  ;  Boolean  :■  False 

—  No  Help  available  for  this  switch. 

RlOOO  Cg  .  Enable_Deallocation  :  Boolean  :■  False 

—  InpTicitly  apply  the  Enable_Deallocation  pragma  to  all  access  types  so 

—  that  storage  can  be  reclaimed  using  Unchecked_Deallocation. 

Rl000_Cg  .  Pull  Debugging  :  Boolean  False 

—  Causes  the  code  generator  to  emit  code  so  that  breakpoints  can  be  set  at 

—  all  Ada  source  constructs,  (e.g.,  null  statements). 

Rl000_Cg  .  Package_Integration  :  Boolean  :=  False. 

—  Causes  the  code  generator  to  integrate  all  packages  for  which 

—  integration  is  possible  (i.e.,  assxane  a  pragma  Integrate  was  associated 

—  with  all  integrable  packages).  When  a  package  is  integrated,  the  code 

—  is  generated  as  if  all  of  its  declarations  were  declared  directly  with 

—  its  parent  package  (no  architectural  module  is  created  for  an  integrated 

—  package ) .  Package  integration  is  not  allowed  for  packages  containing 

—  tasks,  packages  containing  an  initialization  block,  library  unit 

—  packages  or  package  siibunits  whose  bodies  are  separate. 

Rl000_^Cg  .  Page_Limit  ;  Integer  :*  8000 

—  Maximum  nvunber  of  pages  for  segments  in  jobs  which  contain  the  unit; 

—  default  is  8000  pages. 

Directory  .  Require_Internal_Links  :  Boolean  True 

—  Controls  whether  failure  to  create  internal  links  (as  controlled  by  the 

—  Di rectory. Create_Internal  Links  switch)  generates  an  error.  The  default 

—  (True)  is  to  treat  the  failure  to  generate  links  as  an  error  and  to 

—  discontinue  the  operation.  If  the  Directory. Create_Internal__Links 

—  switch  is  set  to  False,  this  switch  has  no  effect.  The  full  switch  name 

—  is  Directory. Require_Internal_Links. 

Rl000_Cg  .  Retain  DeltaljConqpatibility  :  Boolean  :=  True 

—  Causes  the  RlOOlJ  code  generator  to  emit  code  that  is  spec_view/load_view 

—  con^tible  with  code  generated  under  previous  releases  of  the 

—  environment  (releases  before  D_ll_3_0).  A  unit  that  was  coded  with  the 

—  switch  set  one  way  may  freely  reference  a  second  unit  that  was  coded 

—  with  the  switch  set  the  other  way,  but  corresponding  units  in  a  spec 

—  view  and  a  load  view  of  a  given  subsystem  must  be  coded  with  the  switch 

—  set  the  same  way.  A  unit  that  was  coded  under  a  pre-D  11_3_0  release  of 

—  the  environment  is  considered  to  have  been  coded  with  the  switch  set  to 

—  True.  Enabling  the  switch  also  causes  the  code  generator  to  reject  some 

—  valid  Ada  constructs  (e.g.,  constraining  a  inconplete  discriminated 

—  type)  and  to  generate  incorrect  code  for  some  others  (e.g.,  uses  of 

—  exceptions  declared  within  generic  units). 

RlOOO  Cg  .  Seg_Li sting  :  Boolean  :=  False 

—  EnaBles  the  creation  of  RlOOO  object  code  list  files.  Each  file  is 

—  stored  as  an  attribute  of  the  associated  Ada  xonit. 
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Rl000_Cg  .  Terminal_Echo  :  Boolean 

—  If  Asni_Listing  is  set,  then  the  assembly  code  listing  will  be 

—  the  terminal  as  the  code  is  being  generated. 


:=  False 
sent  to 
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APPENDIX  F  OP  THE  Ada  STANDARD 


The  only  allowed  inplementation  dependencies  correspond  to 
implementation-dependent  pragmas,  to  certain  machine-dependent  conventions 
as  mentioned  in  Chapter  13  of  the  Ada  Standard,  and  to  certain  allowed 
restrictions  on  representation  clauses,  llie  implementation-dependent 
characteristics  of  this  Ada  iii5>lementation,  as  described  in  this  Appendix, 
are  provided  by  the  customer.  Unless  specifically  noted  otherwise, 
references  in  this  Appendix  are  to  conpiler  documentation  and  not  to  this 
report.  Implementation-specific  portions  of  the  package  STANDARD,  which 
are  not  a  part  of  Appendix  F,  are: 


package  STANDARD  is 


type  Integer  is  range  -2147483647  ..  2147483647; 

type  Long_Integer  is  range  -9223372036854775808  ..  9223372036854775807; 

type  Float  is 
digits  15 

range  -1.797693134862281993946453440003097057342529296875E308  . . 

1 . 7976931348622ai993946453440003097057342529296875E308 ; 

type  Duration  is 

delta  3.0517578125E-5 

range  -4294967296.0  ..  4294967295.999969482421875; 


end  STANDARD; 
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Appendix  F  for  the  RIOOO  Target 


Appendix  F  describes  the  implementation-dependent  features  of  the  Ada  language,  as  it  is  im¬ 
plemented  for  the  Rational  Environment^”,  the  Rational  architecture,  and  the  RIOOO*  target  If  ypu 
are  using  a  Cross-Development  Facility  (CDF)  to  compile  programs  for  a  non-RlOOO  target,  refer 
to  the  Appendix  F  that  is  provided  with  the  documentation  for  that  CDF. 

Appendix  F  is  a  required  part  of  the  Reference  Manual  for  the  Ada  Programming  Language 
(LRM).  The  following  sections  are  required  by  the  LRM: 

1.  “Implementation- Dependent  Pragmas”  describes  the  form,  allowed  places,  and  effea  of  every 
implementation-dependent  pragma. 

2.  “Implementation-Defined  Attributes”  describes  the  name  and  type  of  every  implementation- 
dependent  attribute. 

3.  "Predefined  Language  Environment”  presents  the  specifications  of  package  System  and  pack¬ 
age  Standard. 

4.  “Support  for  Representation  Clauses”  liscs  .:u  of  the  restrictions  on  representation  clauses. 

5.  “Implementation-Generated  Names”  describes  the  conventions  used  for  any  implementation¬ 
generated  name  denoting  implementation-dependent  components  of  records. 

6.  “Address  Clauses"  describes  the  interprcintion  of  expressions  that  appear  in  address  clauses, 
including  those  for  interrupts. 

7.  “Unchecked  Programming"  describes  any  restrictions  on  unchecked  conversions  and  deallo¬ 
cations. 

8.  “Input/Output  Packages"  describes  any  implementation-dependent  characteristics  of  the 
input/output  packages. 

The  following  sections  contain  additional  information  about  the  RIOOO  compiler; 

9.  “Capacity  Restrictions"  describes  imple.mentation-dependent  limits  on  various  aspects  of 
program  size. 

10.  “Attributes  of  Numeric  Types"  lists  the  values  returned  by  attributes  that  apply  to  integer 
types,  floating-point  types,  and  the  fixed- point  type  Duration. 

11.  “Compilation  in  the  Rational  Environment”  briefly  describes  some  of  the  concepts  that 
underlie  the  Rational  Environment  compilation  system,  provides  a  summary  of  the  separate 
compilation  rules  for  Ada  units  in  the  Environment,  and  lists  the  Environment  library  switches 
that  can  affect  compilation. 
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1.  IMPLEMENTATION-DEPENDENT  PRAGMAS 

The  Environment  accepts  the  pragmas  defined  in  Atuex  B  of  the  LRM,  as  well  as  a  number  of 
additional  pragmas  to  be  used  in  application  software  development  The  first  of  the  following  two 
sections  lists  clarifications  and  restrictions  for  the  pragmas  defined  in  Annex  B.  The  second  of 
these  two  sections  describes  the  Envirorunent-defin^  pragmas. 


1.1.  Pragmas  Defined  in  Annex  B 

For  each  of  the  pragmas  defined  in  Annex  B  of  the  LRM,  this  section  (Table  1)  describes  the 
extent  to  which  it  is  supported  for  the  RIOOO  target  Support  for  these  pragmas  may  differ  for 
other  targets.  Information  about  the  pragmas  diat  are  supported  for  each  non-RlOOO  target  is 
given  in  the  CDF  manual  for  that  target. 


Table!  Pragmas  Defined  in  Annex  B 


Pragma 

Efifect 

Controlled 

Always  implicitly  in  effect  for  the  RIOOO  target  because  the  implementation  does  not 
support  automatic  garbage  collection. 

Elaborate 

Fully  supported. 

Inline 

Has  no  effect  for  the  RIOOO  target 

Interface 

Has  no  effea  for  the  RIOOO  target  because  the  Environment  does  not  support  the 
execution  of  other  languages  on  the  Rational  architecture.  The  specific  behavior  of  this 
pragma  depeixls  on  the  value  of  the  Semantics.Ignoie_lnteifaoe_Pragmas  library  switch  at 
compilation  time.  When  this  switch  is  True,  the  RIOOO  compiler  ignores  the  pragma 
completely.  When  this  switch  is  False,  the  RIOOO  compiler  builds  an  implicit  body  that 
raises  the  Program.Error  exception  whenever  the  subprogram  is  executed. 

List 

Has  no  effea  for  the  RIOOO  urget  because  compiler  listings  are  not  generated. 

Memory_Size 

This  pragma  has  no  effea  for  the  RIOOO  target  because  memory  size  cannot  be  changed. 

Optimiae 

Has  no  effea  for  the  RIOOO  target. 

Pack 

Always  implicitly  in  effect  for  the  RIOOO  target  because  all  records  and  arrays  ate  stored 
packed  in  the  minimum  number  of  bits  that  they  require. 

Page 

Has  no  effea  on  the  compiler,  but  is  interpreted  by  the  priru  spooler  to  cause  a  new  page. 
The  pragma  marks  the  last  line  on  the  page.  The  next  line  is  printed  on  the  next  page. 

Priority 

Priorities  can  be  specified  only  inside  a  task  or  a  library  main  program.  If  multiple  priorities 
are  specified,  only  the  first  priority  specified  is  used.  The  default  priority  is  1.  Ihe  range  is 
0..  5. 

Shared 

Has  no  effea  for  the  RIOOO  target. 

Storage_Unit 

Has  no  effea  for  the  RIOOO  urget  because  the  only  legal  storage-unit  value  is  1. 

Suppress 

Suppresses  only  ElaborationjCheck.  This  pragma  has  no  effea  if  any  other  check  is 
specified. 

System_Name 

Has  no  effect  for  the  RIOOO  Urget  because  the  only  legal  system  name  is  RIOOO. 
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1.2.  Environment-Defined  Pragmas 

For  each  of  the  pragmas  defined  by  the  Environment,  this  section  describes  the  extent  to  which  it 
is  supported  for  the  RIOOO  target.  Support  for  these  pragmas  may  differ  for  other  targets.  Infor¬ 
mation  about  the  pragmas  that  are  supported  for  each  non-RlOOO  target  is  given  in  the  CDF 
manual  for  that  target. 

Table  2  summarizes  the  Environment-defined  pragmas  described  in  this  section. 


Table  2  EnviroTtment-DeJined  Pragmas 


Pragma 

Effect 

Case.Method 

Specifies  one  of  three  search  methods  to  be  used  to  fiiKl  the  selected 
alternative  in  a  case  statement  or  variant  in  a  variant  record. 

Disable.Oeallocation 

Disables  the  deallocation  of  storage  for  the  specified  access  type. 

Eruble_Deallocation 

Enables  the  deallocation  of  storage  for  the  specified  access  type. 

End_Of_Unit 

Specifies  by  its  position  the  boundary  between  adjacent  compilation  units  that 
ate  stored  in  a  text  file. 

Loaded_Main 

Indicates  that  a  unit  is  a  loaded  main  program.  This  pragma  is  automatically 
generated  by  the  Environment  and  never  entered  by  users. 

Main 

Instructs  the  Environment  to  create  a  coded  main  program  when  the  ut\it 
conuining  it  is  promoted  to  the  coded  state. 

Open_Private_Part 

Causes  a  given  package  specification  to  have  an  open  private  part,  causing  the 
private  part  to  be  compiled  whenever  the  package  is  compiled 

Page_Limit 

Specifies  the  minimu.-n  ’.  aiue  for  the  page  limit  of  a  job  executing  the  unit 
containing  the  pragma. 

Private_Eycs_Only 

Causes  the  context  ctau.<;cs  following  the  pragma  to  be  ignored  when  the  unit 
specification  containing  t.nc  pragma  is  compiled. 

1.2.1.  Case.Method 

Pragma  Case_Method  specifies  one  of  three  search  methods  to  be  used  to  find  the  selected 
alternative  in  a  case  statement  or  variant  in  a  variant  record.  This  pragma  must  appear  before  the 
first  alternative  of  the  case  statement  or  before  the  first  variant  of  the  variant  record.  If  this  pragma 
is  omitted,  the  Environment  will  choose  an  appropriate  method  or  combination  of  methods. 

This  pragma  has  the  form: 

pragna  Cas«_Matbod  Ismsrchjamtbod) ; 

where  amerch_mmtbod  is  one  of  the  following; 

•  Linaax__S«asch,  which  causes  the  choices  to  be  compared  against  the  seleaor  sequentially 
in  the  orcter  in  which  they  occur  in  the  .\da  source. 
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•  BinaxyjSMrch,  which  causes  the  choices  to  be  sorted  at  compile  time  and  a  binary  search 
to  be  used  at  run  time  to  selea  the  appropriate  alternative.  If  all  choices  are  equally  probable 
and  there  are  more  than  five  choices,  this  method  is  faster  than  linear  search. 

•  Juapjtabl*,  which  causes  the  selector  to  be  used  to  index  into  a  jump  table.  This  is  the 
fastest  method  but  may  require  large  amounts  of  space  if  the  range  of  choices  is  large. 

For  example: 

cas«  X  is 

pcsgas  Cas«_Msthod  (Binasy__S«srcb)  ; 

wbsn  1  «> _ 

whan  10  •>  .. . 

whsa  101  «>  . . . 

whsa  othsrs  «>  _ 

snd  csss; 


1.2.2.  Disable.Deallocation 

Pragma  DisaUe_Deallocation  specifies  the  name  an  access  type  for  which  deallocation  is 
disabled.  Disabling  deallocation  for  an  access  type  prevents  the  Unchecked.Deallocation 
procedure  from  reclaiming  storage  for  that  type.  This  pragma  is  used  when  deallocation  has  been 
eiubled  for  the  entire  library  (that  is,  the  library  switch  R1000_Cg.Enable_Deallocation  is  set  to 
True)  and  you  want  to  disable  deallocation  for  a  particular  access  type.  (See  also  Section  7,  later 
in  this  appendix.)  This  pragma  has  the  form: 

pxagaa  OlsablaJDaallocatlon  (Mcemss_typm_aaam) ; 

and  must  occur  immediately  within  the  same  declarative  part  as  the  access  type  to  which  it 
applies.  Within  this  declarative  part,  pragma  Disable.Deallocation  can  be  placed  anywhere 
following  the  declaration  of  the  specified  access  type. 


1.2.3.  Enable.Deallocatloa 

Pragma  Enable.Deallocation  specifies  the  name  of  an  access  type  for  which  deallocation  is 
enabled.  This  pragma  erubles  the  Unchecked.Deallocation  procedure  to  reclaim  storage  for  the 
specified  access  type.  This  pragma  is  used  when  deallocation  has  been  disabled  for  the  entire 
library  (that  is,  the  library  switch  R1000_Cg.Enabie_Deallocation  is  set  to  False)  and  you  want  to 
enable  deallocation  for  a  particular  access  type.  (See  also  Section  7,  later  in  this  appendix.)  This 
pragma  has  the  form: 

pragma  Knabla__D«allocatlon  (acc«a«_typ^naaw) ; 

and  must  occur  immediately  within  the  same  declarative  part  as  the  access  type  to  which  it 
applies.  Within  this  declarative  part,  pragma  Enable.Deallocation  may  be  placed  anywhere  fol¬ 
lowing  the  declaration  oS  the  specified  access  type.  Note  that  this  pragma  also  can  be  used  on  a 
generic  formal  to  irKlicate  that  it  should  be  deallocauble. 
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1.2.4.  End_Of_Unit 

Pragma  End_Of_Unit  specifies  by  its  position  the  boundary  between  adjacent  compilation  units 
that  are  stored  in  a  text  file.  This  pragma  has  the  form: 

pragna  BndjOfJtXnlt; 

For  example,  assume  you  are  transferring  compilation  units  from  a  text-based  computer  system  to 
the  RIOOO  and  that  one  of  the  transferred  text  files  contains  multiple  compilation  units.  Assume 
further  that  comments  and  pragmas  occur  between  two  adjacent  compilation  units  in  this  file. 
Then,  before  you  use  Compilation.Parse  to  parse  this  file,  you  can  insert  pragma  End_Of_Unit 
between  the  adjacent  units  to  clarify  which  of  the  comments  and  pragmas  belong  at  the  end  of 
the  preceding  unit  and  which  belong  to  the  beginning  of  the  following  unit  After  the  units  have 
been  parsed,  pragma  End_Of_Unit  is  automatically  removed. 

If  you  omit  this  pragma,  the  Environment  parses  interunit  pragmas  and  comments  by  dividing 
them  at  the  first  full-line  comment  (a  comment  that  stands  alone  on  a  line  and  is  not  the 
continuation  of  a  right-trailing  comment  above  it).  All  pragmas  and  comments  up  to  (but  not 
including)  such  a  comment  are  put  at  the  end  of  the  preceding  compilation  unit,  and  the 
remaining  pragmas  and  comments  are  put  at  the  beginning  of  the  following  compilation  unit 


1.2.5.  Loaded.Maia 

Pragma  Loaded.Main  appears  only  when  generated  by  the  Environment  and  is  never  entered  by 
users.  The  Environment  generates  this  pragma  to  specify  that  a  unit  is  a  .  A  loaded  main  program 
is  an  executable  program  that  is  not  dependent  on  its  source  code;  that  is,  a  loaded  main 
program  will  not  be  obsolesced  if  the  source  code  from  which  it  was  created  is  modified. 
Furthermore,  a  loaded  main  program  can  be  moved  between  RlOOOs  without  having  to  move  and 
recompile  its  source  code.  This  pragma  appears  in  loaded  main  programs  in  the  following  form: 

pragma  Iioa<iad_ICain; 

You  can  create  a  loaded  main  program  from  a  coded  main  program  using  the  Compilation.Load 
procedure.  This  procedure  creates  a  separaie,  self-contained  copy  of  the  main  program’s  code 
segments,  similar  to  an  executable  module  on  other  computer  systems.  The  Compilation.Load 
procedure  automatically  inserts  the  Loadcd_.Main  pragma  in  place  of  the  Main  pragma  in  the 
newly  created  loaded  main  program. 

Because  its  code  segments  are  independent  from  its  source  code,  a  loaded  main  program  is 
unaffected  by  demoting,  and  even  changing,  the  source  code.  Thus,  the  consistency  between  a 
loaded  main  program  and  its  source  code  may  be  lost.  Furthermore,  loaded  main  programs,  like 
code  views,  can  be  debugged  using  the  Rational  debugger  only  if  the  same  version  of  the  original 
source  code  still  exists  in  the  same  location  on  the  same  RIOOO  and  is  still  in  the  coded  state. 
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1.2.6.  Main 

Pragma  Main  instructs  the  Environment  to  create  a  when  the  main  subprogram  containing  the 
pragma  is  promoted  to  the  coded  state.  The  resulting  coded  main  program  has  prelinked  object 
code  for  the  main  subprogram  and  all  of  the  units  in  its  closure.  In  other  words,  elaboration 
infomution  is  generated  at  the  time  the  main  subprogram  is  coded  and  then  retained  for  use 
whenever  the  coded  main  program  is  executed.  When  pragma  Main  is  omitted  from  a  program, 
elaboration  information  is  generated  (and  subsequently  discarded)  each  time  the  program  is 
executed.  Thus,  coded  main  programs  execute  faster  than  nonmain  programs,  so  that  using 
pragma  Main  is  recommended  for  large,  frequently  executed  programs. 

Pragma  Main  must  be  placed  immediately  after  the  end  of  the  spedftcation  or  body  of  a  main 
subprogram.  A  main  subprogram  must  be  a  library-unit  subprogram  that  has  no  subunits  and 
canrx)t  be  a  generic  or  a  generic  instantiation.  A  main  subprogram’s  parameters  (and  result,'  if 
any)  must  be  of  types  defined  in  package  Standard,  in  package  System,  or  in  basic  Environ¬ 
ment-supplied  packages.  Before  a  main  subprogram  can  be  promoted  to  the  coded  state,  all 
compilation  units  in  the  closure  of  the  main  subprogram  also  must  be  in  the  coded  state. 

This  pragma  has  the  following  form,  where  the  three  optional  parameters  are  described  below: 

pragma  Main  (Targat  >>  tMxgmt_nMxam, 

Activity  >■>  "»ctiirity_^filmjaanm" , 

KlaboeatlonjOrdac  *■>  ; 

•  Target:  Specifies  the  name  of  the  target  for  which  the  pragma  is  intended.  This  is  useful 
during  crms-development,  when  you  may  want  to  compile  a  unit  as  a  coded  main  program 
for  one  target  but  not  for  others.  This  parameter  controls  the  applicability  of  the  pragma  in 
the  following  way:  if  the  specified  name  matdies  the  target  key  of  the  enclosing  library,  the 
pragma  is  used;  otherwise,  the  pragma  is  ignored  by  the  current  target  compiler.  Leaving  this 
parameter  unspecified  causes  the  pragma  to  be  \jsed  wherever  the  unit  is  compiled  (that  is, 
the  parameter  value  defaults  to  the  target  referenced  by  the  current  target  key).  Thus,  if  you 
waiu  a  unit  to  be  compiled  as  a  coded  main  prognm  for  the  RIOOO  target,  you  must  either 
specify  this  parameter  with  the  value  RIOOO  or  leave  the  Target  parameter  unspecified 
(depending  on  whether  additional  targets  are  to  be  considered  as  well). 

If  a  unit  is  to  be  compiled  as  a  coded  main  program  for  each  of  several  targets,  the  unit  can 
conuin  one  pragma  Main  for  each  target.  When  the  unit  is  compiled  for  one  of  these  targets, 
the  compiler  filters  out  all  but  the  pragma  Main  whose  Target  parameter  matches  the  target 
key;  if  none  of  the  pragma  Mains  specifies  the  current  target  key,  the  unit  is  not  compiled  as  a 
main  program.  Thus,  you  can  compile  the  unit  for  different  targets  without  having  to  edit  the 
source  code  to  add  or  remove  the  pragma. 

•  Activity:  Specifies  the  name  of  the  activity  to  be  used  when  generating  elaboration  code  for 
the  main  program.  If  a  simple  name  is  specified,  it  is  resolved  relative  to  the  library  containing 
the  main  program.  If  the  Activity  parameter  is  omitted,  the  default  activity  for  the  current 
session  is  used.  Note  that  an  aaivity  is  consulted  only  when  units  in  the  closure  of  the  main 
subprogram  are  defined  in  subsystems. 

•  UabocatlonjOrdae:  Specifies  the  name  of  a  text  file  that  contains  a  list  of  unit  names  in  the 
order  in  which  they  are  to  be  elaborated.  The  specified  elaboration  order  is  subject  to  normal 
Ada  elaboration-ordering  rules;  the  purpose  of  this  parameter  is  to  allow  you  to  specify  a 
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particular  order  where  a  choice  can  be  made.  If  a  simple  name  is  specified,  it  is  resolved 
relative  to  the  library  containing  the  main  program. 

The  contents  of  the  specified  file  must  have  the  same  format  as  indirect  files.  Typically,  this 
means  that  each  line  contains  a  valid  naming  expression.  The  specified  file  need  not  be  a 
complete  list  of  all  units  in  the  program;  rather,  this  file  can  list  just  the  units  whose  order  is 
to  be  specified.  Note  that  the  required  indirect  file  format  is  used  in  the  elaboration-order 
listing  files  that  are  produced  whenever  the  R1000_Cg.Elab_Order_Listing  switch  is  set  to  True 
in  libraries  containing  main  subprograms.  Consequently,  you  can  modify  an  elaboration-order 
listing  file  to  reflect  the  desired  elaboration  order  and  then  specify  it  through  this  parameter. 

To  understand  pragma  Main  in  more  detail,  it  is  necessary  to  understand  what  takes  place  before 
the  Envircmment  actually  executes  a  program.  In  particular,  the  Environment: 

1.  Checks  the  compilation  units  in  the  closure  of  the  program  to  verify  that  they  exist,  are 
complete,  and  are  in  the  coded  state.  Note  that  for  programs  developed  in  subsystems,  the 
current  (or  specified)  activity  is  used  to  determine  the  actual  units  in  the  program’s  closure. 

2.  Computes  a  valid  elaboration  order  for  the  closure  of  the  program,  based  on  the  rules 
specked  in  LRM  10.5.  (If  applicable,  the  file  specified  by  the  Elaboration_Order  parameter  of 
pragma  Main  is  also  taken  into  account.) 

3.  Generates  elaboration  code  that,  when  executed,  causes  all  of  the  units  in  the  program’s 
closure  to  be  elaborated  in  the  order  computed  in  step  2. 

These  steps  are  referred  to  as  prelinktng.  For  programs  that  do  not  contain  pragma  Main, 
prelinking  occurs  when  coded  units  are  promoted  for  execution.  In  this  case,  the  elaboration 
information  is  discarded  after  it  is  executed.  For  programs  that  contain  pragma  Main,  prelinking 
occurs  earlier — specifically,  when  the  main  subprogram  is  promoted  to  the  coded  state.  The 
computed  elaboration  order  and  elaboration  code  are  retained  for  use  each  time  the  program  is 
executed.  Note  that  after  the  prelinking  has  taken  place,  main  programs  written  in  subsystems 
execute  without  consulting  an  activity. 

The  retained  elaboration  information  is  discarded  and  the  main  program  is  demoted  to  installed  if 
any  of  the  units  in  the  program  are  demoted  below  the  coded  state.  In  other  words,  a  coded 
main  program  maintains  a  dependency  on  its  source  code.  To  remove  this  dependency,  you  can 
use  the  Compilation.Load  command  to  create  a  loaded  main  program  from  a  coded  main 
program;  see  Section  1.2.5,  above. 

Bear  in  mind  that  units  in  the  closure  of  a  coded  main  program  are  actually  elaborated  when  the 
main  program  is  called.  If  a  command  or  program  calls  other  coded  main  programs,  and  if  the 
closures  of  these  coded  main  programs  share  any  units,  then  separate  copies  of  the  shared  units 
are  elaborated. 


1.2.7.  Opeii_Private_Part 

Pragma  Open_Private_Part  causes  a  given  package  specification  to  have  an  open  private  part. 
This  pragma  has  the  form; 

pragaa  Op«n_J?riTat«_Part; 
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and  is  effective  only  in  package  specifications  defined  in  spec  views.  Furthermore,  this  pragma 
must  occur  before  the  first  {M-ivate  type  in  a  given  package  specification.  The  effect  of  pragma 
Open_Private_Part  is  not  inherited  by  nested  packages;  this  pragma  must  be  included  in  each 
package  that  is  to  have  an  open  [Mlvate  part 

By  default,  packages  in  spec  views  have  closed  private  parts,  ^ich  support  the  conceptual 
separation  of  private  parts  from  visible  package  declarations.  When  packages  with  closed  private 
parts  are  compiled  in  a  spec  view,  the  private  parts  of  these  packages  are  ignored  by  the 
compiler.  Consequently,  the  private  parts  of  exported  packages  can  be  changed  in  a  load  view 
Y^thout  renderir^  that  load  view  incompatible  with  the  compiled  spec  view  (and  without 
requiring  the  corresponding  changes  to  be  made  in  the  spec  view,  which  would  necessitate  the 
recompilation  of  client  views). 

Pragma  Open_Private_Part  overrides  the  default  treatment  of  private  parts  in  spec-view  packages, 
causing  the  private  parts  to  be  compiled  whenever  the  packages  containing  them  are  compiled. 
This  allows  the  compiler  to  take  advantage  of  the  specific  type  information  in  the  private  parts, 
resulting  in  more  efficient  code.  However,  clients  erf  packages  with  open  private  parts  must  be 
recompiled  whenever  any  of  the  private  parts  are  changed.  Furthermore,  changes  to  private  parts 
must  ^  made  in  both  the  spec  and  load  views  to  preserve  compatibility  between  these  views. 
Finally,  pragma  Private_Eyes_Only  has  no  effect  when  private  parts  are  open. 
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Pragma  Open_Privaie_Part  also  may  appear  in  package  specifications  that  are  defined  in  load 
views  or  in  libraries  outside  subsystems.  However,  because  private  parts  are  always  open  in  such 
views  and  libraries,  the  pragma  is  ignored.  For  more  information,  see  the  “Key  Concepts”  section 
in  the  Project  Management  (PM)  book  of  the  Rational  EmHronment  Reference  Manual 

1.2.8.  Pagc.IJmit 

Pragma  Page_Limit  specifies  the  minimum  value  for  the  page  limit  of  a  job  executing  the  unit 
containing  the  pragma.  The  page  limit  is  the  number  of  virtual  memory  pages  (containing  1024 
bytes  each)  that  can  be  creat^  by  the  job  that  elaborates  the  unit  in  which  the  pragma  appears. 

This  pragma  has  the  form: 

pragma  Pag«_Llffllt  (positivm_integer) ; 

and  is  allowed  after  the  end  of  a  unit  specification  or  body. 

Note  that  the  value  of  this  pragma  is  ignored  if  it  is  less  than  either  of  the  values  given  by  the 
library  switch  R1000_Cg.Page_Limit  and  the  session  switch  DefaultJ[ob_Page_LiiniL  In  other 
words,  the  compiler  uses  the  maximum  of  the  values  given  by  the  pragma  and  these  two 
switches.  For  a  more  detailed  description,  see  the  reference  entries  for  the  System_Utilities.Get- 
_Page_Counts  and  System_Utilities.Set_Page_l.imit  procedures  in  the  System  Management  Utilities 
(SMU)  book  of  the  Rational  Environment  Reference  Manual 

1.2.9.  Privatc_Eyes_Oiily 

Pragma  Private_Eyes_Only  causes  the  context  clauses  following  the  pragma  to  be  ignored  when 
the  unit  specification  containing  the  pragma  is  compiled.  Such  context  clauses  can  be  ignored 
only  if  they  are  required  only  by  closed  private  parts  in  a  unit  specification  in  a  subsystem  spec 
view.  For  more  information,  see  the  “Key  (Concepts”  section  in  the  Project  Management  (PM) 
book  of  the  Rational  Environment  Reference  Manual 

This  pragma  has  the  form: 

pragma  Pxlvat«_By«s_pnly; 

and  has  no  effect  in  any  of  the  following  situations: 

•  When  private  parts  are  open,  as  in  units  containing  pragma  Open_Private_Part 

•  In  generic  units,  for  which  the  private  parts  are  always  open 

•  In  units  located  outside  subsystems 


2.  IMPLEMENTATION-DEFINED  ATTRIBUTES 

This  section  describes  the  implementation-defined  attributes  for  the  RIOOO  target. 
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2.1.  P’Compiler_Version 

For  a  prefix  P  that  denotes  an  object,  type,  exception,  package,  or  subprogram,  this  attribute 
yields  the  version  of  the  compiler  that  was  used  to  generate  code  for  the  unit  containing  the 
definition  P.  The  value  returned  by  this  attribute  is  of  type  string — for  example,  "11.4.0". 

2.2.  PDeclaration.Number 

For  a  prefix  P  that  denotes  an  object,  type,  exception,  package,  or  subprogram,  this  attribute 
yields  the  declaration  number  that  is  associated  with  the  declaration  of  P.  '^thin  a  subsystem, 
every  declaration  in  a  given  library-unit  specification  is  identified  by  a  unique  declaration  number. 
The  value  returned  by  this  attribute  is  a  Long_Integer. 

Taken  together,  the  values  of  FSubsystem_Number,  P’Unit_Number,  and  P’Declaration_Number 
provide  a  unique  way  of  identifying  a  given  declaration  P  in  a  given  library-unit  specification  in  a 
given  subsystem.  See  also  TType_Key. 


2.3.  P’Subsystem.Number 

For  a  prefix  P  that  denotes  an  object,  type,  excej^on,  package,  or  subprogram,  this  attribute 
yields  the  subsystem  identification  numb^  of  the  subsystem  containing  the  unit  in  which  P  is 
declared.  Every  primary  subsystem  on  an  RIOOO  has  a  unique  subsystem  identification  number;  in 
fact,  a  given  subsystem  identification  number  is  unique  across  all  RlOOOs.  Note  that  secondary 
subsystems  always  have  the  same  subsystem  identification  number  as  the  primary  subsystem  with 
which  they  are  associated,  even  if  they  reside  on  different  machines.  The  value  returned  by  this 
attribute  is  a  Long_Integer. 

Taken  together,  the  values  of  FSubsystem_Number,  FUnit_Number,  and  P'Declaration_Number 
provide  a  uniique  way  of  identifying  a  given  declaration  P  in  a  given  library-unit  specification  in  a 
given  subsystem.  See  also  TType_Key. 


2.4.  PTarget_Key 

For  a  prefix  P  that  denotes  an  objea,  type,  exception,  package,  or  subprogram,  this  attribute 
yields  the  portion  of  the  target  key  that  indicates  the  compiler  that  was  used  to  generate  code  for 
the  unit  containing  the  definition  of  P.  The  value  returned  by  this  attribute  is  of  type  string — for 
example,  "RIOOO". 


2.5.  TType.Key 

For  a  prefix  T  denoting  a  type  name,  this  attribute  yields  a  string  representation  of  the  triple 
consisting  of  the  subsystem  identification  number,  the  unit  number,  and  the  declaration  number 
for  T — for  example,  "612.14.19".  Thus,  the  string  returned  by  this  attribute  uniquely  identifies  type 
T.  This  attribute  typically  is  used  when  passing  messages  of  a  given  type  over  a  network  to 
ensure  that  the  reader  and  writer  agree  on  the  type  to  use  when  interpreting  the  message. 
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Similarly,  this  attribute  is  used  when  storing  values  of  the  type  in  a  file  to  ensure  that  the  reader 
and  writer  agree  on  the  type  to  use  when  interpreting  data  in  the  file. 

See  also  the  P'Subsystem_Number,  P’Unit_Number,  and  P’Dedaration_Number  attributes,  which 
return  the  integer  representations  of  the  individual  components  of  the  TType_Key  value. 


2.6.  P*Uiiit_Niimber 

For  a  prefix  P  that  denotes  an  object,  type,  exception,  package,  or  subprogram,  this  attribute 
yields  the  unit  number  of  the  unit  in  which  P  is  declared.  Within  a  given  subsystem,  every  library 
unit  is  identified  by  a  unique  unit  number.  The  value  returned  by  this  attribute  is  a  Long_Integer. 

Taken  together,  the  values  of  P’Subsystem_Number,  P’Unit_Number,  and  P’Declaration_Numter 
provide  a  unique  way  of  identifying  a  given  declaration  P  in  a  given  library-unit  specification  in  a 
given  subsystem.  See  also  TType_Key. 


3.  PREDEFINED  LANGUAGE  RNVmONMENT 

This  section  presents  the  implementation-dependent  portions  of  package  System  and  package 
Standard.  Note  that  these  packages  are  presented  in  an  elided  form,  generally  omitting 
declarations  that  are  i  ot  implementation-dependent  or  that  are  reserved  for  internal  use  only. 
Additional  information  about  packages  Standard  and  System  is  in  the  Programming  Tools  (PT^ 
book  of  the  Rational  Environment  Reference  Manual. 

3«1.  Package  System 

Package  System  defines  various  implementation-dependent  types,  objects,  and  subprograms. 

packag*  Systom  is 

typ«  Address  Is  private; 

Nuil_Addxess  :  constant  Address; 

type  Hame  is  (RIOOO) ; 

Systam_Naske  :  constant  Name  :=  RIOOO; 

Bit  :  constant  : a  1 ; 

Storage_Unit  :  constant  1  *  Bit; 

Word_Size  ;  constant  128  *  Bit; 

Byte_Sire  :  constant  :=  8  *  Bit; 

Megabyte  :  constant  :=  (2  **  20)  *  Byte__Size; 

Meniory_Size  :  constant  32  *  Megabyte; 

—  System-dependent  named  numbers 

Min_lnt  :  constant  :»  Long_Intager'Pos  (Iiong_Integer' First) ; 

Maj:_lnt  :  constant  :=  Long_Integer' Pos  (Long_Integer' Last) ; 
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lUx_Dlglt8  :  constant  15; 
llax_Mantlssa  :  constant  :*  63; 
rln«_Dalta  :  constant  1.0  /  (2.0  **  63); 

Tick  :  constant  :■  200.0K-9; 

subtypa  Pxloxlty  Is  Intagar  xanga  0  . .  5; 

—  Bytas  ara  basic  units  of  tsansatlsslon/racaptlon  to/£som  I/O  davlcas 

typa  Byta  Is  naw  Natural  xanga  0  . .  255; 

typa  Byta_Stxlng  la  array  (Natural  xanga  O)  of  Byta; 

—  Xzcaptlons  ralsad  by  UncbackadMConTarslon  or  unchacked_Converslons ; 

—  aay  also  rasult  from  apac/load  vlaw  Incoopatlbllltlas  or 

—  from  coiif>llar/inlcxocoda  arxors 

Typa_Brror  :  axcaptlon; 

CapabllltyJError  :  axcaptlon; 

Assaxtlon_Brror  :  axcaptlon; 

—  Kxcaptlons  rasultlng  from  spac/load  ▼law  Incompatibilities  or 

—  from  coapllar/mlcrocoda  errors 

Fraaia_Bstabll8h_Brror 
HaapJPolntasjCopy_JBrror 
Illagal_Instsuctlon 
Illagal^rramaJExlt 
Xllagal_Baap_Acca88 
IllagaljRafaranca 
Xnwalld_Packaga__Valua 
Nachlna_Rostrlctlon 
lllcsocoda_As  slst JError 
Nonaxlstant_Paga_Error 
Nonaxlstant_Spaca_Brror 
Oparand_jClass__Brror 
llacosd_riald_Error 
Salact_nsa_Error 
OnsupportadJPaatura 
Otlllty;_Esror 
Vlslblllty_Brror 
Wrlta__To__Raad_Only_Paga 

and  System; 


3.2.  Pack^e  Standard 

Package  Standard  defines  all  of  the  predefined  identifiers  in  the  language. 

package  Standard  Is 

typa  Boolean  Is  (Falsa,  True) ; 
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typ«  Intagve  is  rang*  -2147483647  . .  2147483647; 
subtyp*  natural  is  Integer  range  0  ..  2147483647; 
subtype  Positive  is  Integer  range  1  . .  2147483647; 

type  Long_Integer  is  range  -9223372036854775808  . .  9223372036854775807; 

type  Float  is 
digits  15 

range  -1.79769313486231E-<-308  ..  1.79769313486231B-I-308 

type  Duration  is 

delta  3.0517578125B-5 

range  -4.29496729600000E+09  ..  4.29496729599997E-I-09 

type  Character  is  . . . ; 
for  Character' Size  use  8; 

type  String  is  array  (Positive  range  o)  of  Character; 
pragsa  Pack  (String) ; 


package  Ascii  is 

Constraint_Brror 

MuiDeric__Brror 

Storage_Brror 

TaskingJError 

Prograai_Brror 


. . .  end  Ascii; 

:  exception; 

:  exception; 

:  exception; 

:  exception; 

:  exception; 


end  Standard; 


4.  SUPPORT  FOR  REPRESENTATION  CLAUSES 

This  section  describes  the  Environment's  support  for  representation  clauses  for  the  RIOOO  target. 
In  particular,  this  section  describes  the  default  representation  of  each  type  (that  is,  the  represen¬ 
tation  that  is  used  in  the  absence  of  representation  clauses)  as  well  as  the  values  that  can  be  used 
in  the  representation  clauses  for  these  types.  The  various  types  are  listed  below,  along  with  the 
kinds  of  representation  clauses  that  apply  to  them: 

•  Integer  types:  size  length  clauses 

•  Enumeration  types;  size  length  clauses  and  enumeration  representation  clauses 

•  Floating-point  types:  size  length  clauses 

•  Fixed-point  types:  size  length  clauses  and  small  length  clauses 

•  Access  types:  size  length  clauses  and  storage-size  length  clauses 

•  Task  types:  size  length  clauses  and  storage-size  length  clauses 

•  Array  types:  size  length  clauses 

•  Record  types:  size  length  clauses  and  record  representation  clauses 
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Note  that,  in  addition  to  representation  clauses,  the  LRM  permits  another  mechanism  for  control¬ 
ling  the  representation  of  types — namely,  predefined  and  implementation-defined  pragmas.  How¬ 
ever,  such  pragmas  do  not  play  an  important  role  for  the  RIOOO  target.  In  particular,  the 
predefined  pragma  Pack  never  needs  to  be  specified,  because  packed  representation  of  arrays 
and  records  is  always  in  effect.  Furthermore,  the  RIOOO  target  supports  no  implementation- 
defined  pragmas  for  controlling  representation. 


4.1.  General  Information  about  Scalar  Object  Size 

Compilers  on  other  computer  systems  typically  represent  the  sizes  of  scalar  objects  in  terms  of  the 
sizes  of  their  base  types.  Because  the  sizes  of  base  types  are  known  at  compile  time,  the 
representation  of  scalar  object  sizes  is  also  determined  statically,  even  if  a  dynamic  range 
constraint  is  present.  In  contrast,  the  compiler  on  the  RIOOO  represents  scalar  objects  in  terms  of 
subtypes  rather  than  base  types.  This  choice  has  two  consequences.  First,  a  scalar  object’s  size  is 
generally  smaller  than  that  of  its  base  type,  because  the  RIOOO  compiler  attempts  to  make 
subtypes  as  small  as  possible.  Secondly,  the  representation  of  scalar  objects  whose  subtypes  have 
dynamic  ranges  is  actually  determined  at  run  time,  because  this  representation  is  not  tied  to  the 
statically  known  sizes  of  base  types. 


4.2.  Integer  Types 

The  RIOOO  compiler  supports  two  predefined  integer  base  types: 

typ«  Int<ig«e  Is  xangs  -2**31  +  1  .  .  2**31  -  1; 

typm  Iiong_Int«g«x  Is  range  -2**63  . .  2**63  -  1; 

Type  declarations  of  the  following  form  are  implicitly  derived  from  type  Long_Integer  (in  this  and 
the  following  examples,  L  stands  for  the  low  bound  and  H  stands  for  the  high  bouncD: 

type  T  Is  range  !•  . .  H; 

Accordingly,  the  following  are  true: 

T' Base' First  »  Iiong_Integer' First 
T' Base' Last  «  Ziong__Integer' Last 

Note  that  L  and  H  must  fall  within  the  bounds  of  Long_Integer;  if  they  do  not,  the  type 
declaration  is  rejeaed. 


4.2.1.  Representation  of  Integer  Types 

All  integers  are  represented  as  two's  complement  binary  numbers.  The  two  predefined  types. 
Integer  and  Long_Integer,  have  sizes  of  32  and  64  bits,  respectively.  All  arithmetic  operations  on 
integers  are  carried  out  using  64-bit  arithmetic.  Note  that  type  Integer  is  symmetric  about  zero, 
but  Long_Integer  is  not — Long_Integer  has  one  more  negative  value  than  it  has  positive  values,  as 
allowed  by  LRM  3.5.4(7).  Thus,  Long_Integer  uses  all  possible  64-bit  values,  whereas  Integer  uses 
all  but  one  of  the  possible  32-bit  values. 
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4.2.2.  Minimum  Sizes  of  Integer  Types 

The  minimum  possible  size  of  an  integer  type  is  the  minimum  number  of  bits  required  for 
representing  that  type  in  the  RIOOO  architecture.  In  general,  the  minimum  size  of  an  integer 
subtype  or  derived  type  is  less  than  or  equal  to  the  minimum  size  of  its  parent  type. 

Minimum  sizes  are  computed  according  to  the  following  rules  (these  rules  apply  even  if  the 
expressions  L  and  H  are  not  static,  in  which  case  the  sizes  are  computed  at  run  time): 

1.  With  constraints,  subtypes  and  derived  types  are  either  the  same  size  or  smaller  than  the  size 
of  the  parent  type.  Thus: 

subtyp*  S  is  Zntagar  rang*  L  . .  B;  ->  S' Sir*  <»  Int*g*r'Slz* 

t3fp*  O  la  naw  S  rang*  L  ..  H;  D'Siz*  <"  S'Siza  <»  Integer' Slza  ^ 

In  particular,  the  sizes  of  subtypes  and  derived  types  with  constraints  depend  on  the  bounds 
of  the  specified  range: 

a.  If  the  range  Is  null  (that  is,  L  >  H),  the  size  is  zero.  For  example: 
type  TO  la  range  4  ..  2;  —  TO' Size  »  0 


b. 


If  the  range  is  unsigned  (that  is,  0  L H),  the  size  is  the  smallest  integer  S  such  that  H  S 
2*  -  1.  For  example: 

type  T1  Is  range  0  . .  7;  —  Tl'Slz*  »  3 

type  T2  Is  naw  Xiong_Znt*g*r 

range  0  ..  Iiong_Znt*ger' Last;  —  T2'Slza  >  63 

c.  If  the  range  is  signed  (that  is,  L  <  0),  the  size  is  the  smallest  integer  S  such  that  abs(H)  S 
2*-*  -  1  and  abs(L)  S  2*-*.  For  example: 

type  T3  Is  new  Integer  range  -8  ..  15;  —  T3'Slze  >  5 

2.  Without  constraints,  subtypes  and  derived  types  are  always  the  same  size  as  their  parent 
types.  Thus: 

subtype  S  Is  Integer;  —  S' Size  •  Integer' Size 

type  D  Is  new  S;  —  D'Slz*  •  S' Size  »  Integer' Size 


4.2.3.  Sizes  of  Integer  Types 

In  the  absence  of  an  applicable  size  length  clause,  an  irtteger  subtype  or  derived  type  is 
represented  using  the  minimum  possible  size,  as  defined  by  rules  1  and  2  in  Section  4.2.2. 
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When  an  applicable  size  length  clause  is  present,  an  integer  subtype  or  derived  type  is 
represented  using  the  size  specified  by  the  clause.  The  size  specified  in  a  size  length  clause  must 
be  greater  than  or  equal  to  the  minimum  required  size.  Furthermore,  the  specified  size  must  be 
less  than  or  equal  to  64.  For  example: 

typ«  T1  is  rang*  0  ..  7;  —  Tl'Slzs  >  3 

typs  T4  is  nsw  Tl; 

fox  T4'Siz«  ua«  16;  —  T4'Slzs  »  16 

Without  the  size  length  clause,  the  size  of  T4  (which  has  no  constraints)  would  be  3,  the  size  of 
its  parent  type.  The  size  length  clause  specifies  a  value  greater  than  the  default  size  (3)  and 
therefore  overrides  it  (A  size  length  clause  such  as  for  T4'  Slzs  uss  2;  would  be  rejected.) 


4.2.4.  Sizes  of  Objects 

An  object  of  integer  type  has  the  same  size  as  the  subtype  used  to  declare  the  object.  For 
example: 

typ«  Tl  Is  zanga  0  . .  7;  —  Tl'Slza  «  3 

X  ;  Tl;  —  X'Slza  «  3 

X  :  Tl  rang#  0  ..  3;  —  X'Slza  «  2,  tha  slza  of 

—  tha  anonymous  subtypa 

4.3.  Enumeration  Types 

The  representation  of  enumeration  types  be  controlled  using  enumeration  representation 
clauses  and  size  length  clauses.  The  following  seaions  describe  the  representation  of  enumer¬ 
ation  types  in  the  absence  of  these  clauses  as  well  as  the  implementation-dependent  restrictions 
using  these  clauses. 


4.3.1.  Representation  of  Enumeration  Types 

Enumeration  types  correspond  directly  to  integer  types.  This  correspondence  arises  from  the  fact 
that  each  of  the  literals  in  an  enumeration  t>  pe  is  associated  with  an  integer  value.  Consequently, 
the  range  of  enumeration  literals  is  represented  as  a  range  of  integer  values. 

In  the  absence  of  an  applicable  enumeration  representation  clause,  each  enumeration  literal  in  an 
enumeration  type  is  represented  by  its  position  number.  Thus,  for  an  enumeration  type  with  N 
enumeration  literals,  the  literals  are  represented  by  the  integers  0, 1,  2, ...,  N  -  1. 

Enumeration  representation  clauses  can  be  used  to  specify  nondefault  integer  representations  for 
the  literals  in  enumeration  types.  For  example,  the  enumeration  representation  clause  below 
causes  the  literals  A,  B,  and  C  to  be  represented  by  the  integers  15,  16,  and  101,  respectively: 

typ«  Tl  is  (A,  B,  C) ; 
for  Tl  uss  (15,  16,  101); 

Enumeration  representation  clauses  must  specify  integers  in  the  range  -2^'  +  1  ..  23*  -  1. 
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4.3.2.  Minimum  Sizes  of  Enumeration  Types 

Because  enumeration  types  are  translated  into  ranges  of  integer  values,  the  minimum  size  for  an 
enumeration  type  is  computed  using  rules  1  and  2  given  in  Section  4.2.2,  above.  When  applying 
these  rules  to  an  enumeration  type  T,  note  that  the  low  bound  L  stands  for  the  integer 
representation  of  the  first  literal  in  the  range  CTFirst)  and  the  high  bound  H  stands  for  the  integer 
representation  of  the  last  literal  in  the  range  CTLasO.  For  example: 

typ«  T1  Is  (A,  B,  C);  —  Tl'Slss  -  2  by  suls  l.b. 

—  (L  *  0  and  H  a  2) 

subtyps  S  Is  Tl;  —  8'Siss  ■>  Sl'Slss  by  suls  2. 

typs  T2  Is  n«w  Tl  sang*  A.  .A;  —  T2'SiBa  *  0,  by  zula  l.b. 

—  (X,  «  0  and  H  “  0) 

typa  T3  la  naw  Tl;  —  TS'Slza  »  32  by  rule  l.c. 

for  T3  use  (Integer' First,  0,  Integer' Last) ;  —  (L  ■  Integer' First  and 

—  Ha  Integer' Last) 

type  T4  la  new  T3  range  B. .C;  —  T4'Slze  a  31  by  rule  l.b. 

— •  (L  a  0  and  H  a  integer' Last) 


4.3*3«  Sizes  of  Enumeration  Types  and  Obfects 

In  the  absence  of  an  applicable  size  length  clause,  an  enumeration  type  is  represented  using  the 
minimum  possible  size  (see  the  previous  section). 

When  an  applicable  size  length  clause  is  present,  an  enumeration  type  is  represented  using  the 
size  specified  by  the  clause.  As  for  integer  types,  the  size  specified  in  a  size  length  clause  must  be 
greater  than  or  equal  to  the  minimum  required  size  and  must  be  less  than  or  equal  to  64. 
Following  are  examples  of  size  length  clauses  used  with  enumeration  types: 

type  Tl  Is  (A,  B,  C);  —  (Mlniaua  posslbl*  wslus  of  Tl'Slce  Is  2) 

for  Tl'Slz*  US*  8;  —  Tl'Slz*  «  8 

typ*  T3  Is  n«w  Tl;  —  (MlnisBaa  posslbl*  vslu* 

for  T3  us*  (Int*g*r' First,  0,  Intsgsr'Lsst) ;  —  of  T3'Slz*  Is  32) 

for  T3'Slz*  us*  €4;  -***  T3'Slz*  «  64 


4.4.  Floating-Point  Types 

The  R1(X)0  compiler  supports  a  single  predefined  floating-point  base  type: 
typ*  Float  Is  digits  15 

rang*  -1.79769313486231B-»-308  ..  1.79769313486231B-f308; 
A  floating-point  type  declaration  of  the  following  form  is  implicitly  derived  from  type  Float: 
typ*  T  Is  digits  D  [rang*  L  . .  H] ; 
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Accordingly,  the  following  are  true: 

X' Baa*' First  «  Float' First 
X'Basa'Last  •  Float' X^st 
T'Basa' Digits  «  Float 'Digits 


4.4.1.  Representation  of  Floating-Point  Types 

Values  of  type  Float  arc  represented  using  the  double  (64-bit)  float  format  specified  by  the  IEEE 
Standard  for  Binary  Floating  Point  Arithmetic  (ANSI/IEEE  Std.  754-1985).  The  RIOOO  compiler 
does  not  support  “not  a  number"  values  and  the  value  negative  zero.  The  encodings  for  these 
values  are  considered  invalid. 

The  bit  pattern  for  floating-point  types  consists  of  the  following,  arranged  from  left  to  right,  for  a 
total  of  64  bits: 

•  1  bit  for  the  sign 

•  11  bits  for  the  exponent 

•  52  bits  for  the  mantissa 

The  sign  bit  is  interpreted  conventionally  (0  is  positive,  1  is  negative). 

The  exponent  bits  are  interpreted  as  an  11 -bit  unsigned  integer  biased  by  -1022.  That  is,  if  all  11 
of  the  exponent  bits  are  0,  the  exponent  is  -1022;  if  all  11  of  the  exponent  bits  are  1,  the 
exponent  is  1025. 

The  interpretation  of  the  mantissa  bits  depends  on  the  value  of  the  exponent: 

•  If  the  exponent  equals  the  largest  value  (1025),  then  the  value  is  “not  a  number,"  and  the 
mantissa  bits  are  not  interpreted.  Note  thac: 

—  No  floating-point  operation  with  valid  operands  will  return  such  a  value;  instead,  excep¬ 
tions  are  raised  wherever  the  IEEE  standard  specifies  that  “not  a  number"  be  returned. 

—  Floating-point  operations  with  “not  a  number”  values  as  operands  yield  unpredictable 
results.  “Not  a  number"  values  can  arise  only  through  uninitialized  variables  (x*  unchecked 
conversion. 

•  If  the  exponent  equals  the  smallest  value  (-1022),  then  the  mantissa  bits  are  interpreted  as  a 

52- bit  unsigned  integer  with  an  implicit  scaling  factor  of  2~’^.  In  other  words,  the  mantissa  is  a 
multiple  of  2*’*  that  lies  in  the  range  0.1-  2-«.  This  is  the  gradual  underflow  case. 

•  If  the  exponent  is  a  value  between  -1022  and  1025,  the  mantissa  bits  are  interpreted  as  if  an 
extra  bit  (a  1)  preceded  the  remaining  52.  Accordingly,  the  mantissa  bits  are  interpreted  as  a 

53- bit  unsigned  integer  with  an  implicit  leading  1  (which  ncxmalizes  the  mantissa)  and  an 
implicit  scaling  factcx  of  2-».  In  other  words,  the  mantissa  is  a  multiple  of  2-’*  that  lies  in  the 
range  0  ..  1  -  2-’5. 

You  can  use  the  preceding  information  to  convert  bit  patterns  into  mathematical  values  (and  vice 
versa).  For  example,  these  steps  convert  the  hc.xadecimal  bit  pattern  16#4008_0000_0000_0000#  to 
the  mathematical  value  3.0: 
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1.  Conveit  the  first  three  hexadecimal  digits  (400)  to  binary  notaticxi:  2#0100_0000_0000*. 

2.  Obtain  the  sign  from  the  binary  notation.  The  sign  is  the  leftmost  bit,  0,  which  is  positive. 

3-  Gdculate  the  exponent  from  the  remaining  bits  in  the  binary  notation.  To  do  this,  evaluate  the 
integer  represented  by  these  bits  (1024)  and  subtract  the  bias:  1024  -  1022  -  2. 

4.  Calculate  the  mantissa  from  the  remaining  13  digits  of  the  hexadecimal  notation.  To  do  this: 

a.  Insert  the  implicit  leading  l:l6#18_0000_0000_0000#. 

b.  Evaluate  the  integer  represented  by  this  hexadecimal  notation  (24  x  2^  and  multiply  by 
the  scaling  factor  (24  x  2*)  x  2-m  -  0.75. 

5.  Calculate  the  mathematical  value  of  the  entire  bit  pattern  using  the  usiial  formula: 

s^nx.  mantissax 

Thus,  the  value  is:  1  x  0.75  x  2*  -  3.0. 

Table  3  lists  various  mathematical  values  and  their  floating-point  representations. 


TabtaS  FtooHag-Poimt  RepresemtaHomsi^MatbemaUcatVaiues 


Mathematical  Value 

Floatlag-Point  Representatioii 

Comments 

2  -  -1074 

16<0000_0000_0000_0001# 

Smallest  positive  representable  number 

(?  -  1024)  -  (2  •*  971) 

16#7FEF_FFFF_FFFF_FFFF# 

Largest  positive  represenuble  number 
(StarxlardFloafLa^ 

2-53 

16*4340.0000_0000_0000# 

Note:  (2  —  53)  +  1  is  the  smailest  positive 
unr^msentable  integer 

(2  -  53)  ♦  2 

16<»4340 0000 0000 0001# 

0.00 

16<*0000_0000_0000_0000# 

0.50 

0.75 

16#3FE8_0000_0000_0000# 

1.00 

16#3FFO_0000_0000_0000* 

2.00 

l6<MO0O_00OO_O00O_O0OOe 

3.00 

l6<M008_0000_0000_OOOOe 

4.00 

16<M010 0000 0000 0000* 

2 --63 

i6#3coo_oooo_oooo_oooo# 

System.Fine_DeIta 

-2-63 

l6#C3EO_000O_000OJ)00O# 

Sysietn.Min_lnt 

(2  -  63)  -  1 

16#43DF_FFFF_FFFF_FFFF# 

System.Max_Int 

(Note:  same  represeruation  as  next  entry) 

(2  -  63)  -  (2  -  ’0) 

16<M3DF_FFFF_FFFF_FFFF# 

Largest  representable  number  less  than  or 
equal  to  Sy5tem.Max_Int 
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4.4.2.  Size  of  Floating-Point  Types  and  Objects 

The  size  of  all  floating-point  types,  subtypes,  and  objects  is  64  bits.  A  size  length  dause  is 
allowed  for  a  floating-point  type  only  if  it  specifies  a  value  of  64. 


4.5.  Fixed-Point  Types 

The  RIOOO  compiler  supports  a  set  of  anonymous  predefined  fixed-point  base  types  of  the 
following  form: 

typm  W  !•  dalta  D  rang*  -(2. 0**63)  /  S  ..  (2. 0**63  -  1.0)  /  S; 
foe  r' Small  ua*  S; 

Exactly  one  such  predefined  fixed-point  type  exists  for  every  value  of  S  such  that  S  is  in  the  range 
2.0-®  ..  2.0®  and  can  be  represented  as  a  rational  number  N/M  (where  1  S  N,M  S  2®)  or  S  is  a 
power  of  two  in  the  range  2.0-’°®  ..  2.09^.  Common  special  cases  for  S  are  integers  (for  example, 
2.0  or  10.0)  and  redprocals  of  integers  (for  example,  0.5  or  0.1). 

A  fixed-point  type  dedaration  of  the  following  form: 

typ*  T  is  dalta  D  rang*  !•  . .  H; 
for  T' Small  ua*  S; 

is  implicitly  derived  From  the  anonymous  predefined  fixed-point  type  F  for  which  FSmall  - 
TSmall.  The  low  bound  L  and  the  high  bound  H  must  be  real  numbers  such  that  both  L  +  S  and 
H  -  S  fall  within  the  range  F'First  ..  F’Last.  If  no  such  predefined  base  type  exists,  the  type 
declaration  is  rejeaed. 

A  fixed-point  type  dedaration  T  with  no  small  length  dause  is  implidtly  derived  from  the 
predefined  fixed-point  base  type  F  for  which  F'Small  is  the  largest  power  of  two  that  is  not 
greater  than  TDelu  (LRM  3.5.9). 

The  RIOOO  compiler  supports  a  single  named  predefined  fixed-point  type  called  Diiration: 

typ*  Duration  la  dalta  2.0**  (-15)  rang*  -2. 0**31  ..  2. 0**31  -  1.0; 

Note  that  Duration  is  not  itself  a  base  t>pe  but  is  a  first-named  subtype  of  the  following 
anonymous  predefined  base  type: 

typ*  Duration' Baa*  la  dalta  2.0** (-15)  rang*  -2. 0**48  ..  2. 0**48  -  1.0; 
for  Duration' Baa*' Small  ua*  2.0**(-15); 


4.5.1.  Representation  of  Fixed-Point  Types 

A  value  X  of  a  fixed-point  type  T  is  represented  as  a  multiple  of  rSafe_Small.  In  particular,  this 
multiple  is  the  two’s  complement  integer  XA'  Safe.Small  (if  X  is  not  divisible  by  T’Safe_Small, 
then  the  value  X/TSafe_Small  is  rounded  to  the  nearest  integer).  For  example,  if  X  -  3.0  and 
TSafe_SmaJI  -  0.5,  then  the  value  of  X  is  represented  by  the  integer  3.0/0.5  -  6.  Note  that  in  most 
cases,  TSmall  can  be  used  instead  of  TSafe_Small  when  determining  integer  representation  of 
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fixed-point  values.  That  is,  TSafe.Small  -  TSmall  except  where  T  is  a  subtype  that  has  a  different 
delta  than  its  parent  type. 

In  the  absence  of  an  applicable  small  length  clause,  the  value  of  TSmall  and  the  related  value 
TSafe_Small  are  determined  by  the  rules  given  in  LRM  3.5.9. 

When  an  applicable  small  length  clause  is  present,  a  fixed-point  type  is  represented  using  the 
value  of  smaU  specified  by  the  clause.  A  small  length  clause  is  accept  only  if  it  specifies  a  value 
S  such  that  S  is  in  the  range  2.0-^  ..  2.0^  and  can  be  represent^  as  a  rational  number  N/M 
(where  1  S  N>I  ^  2®)  or  S  is  a  power  of  two  in  the  range  2.0-*®**  ..  2.0***.  To  guarantee  the 
precision  of  results,  the  RIOOO  compiler  currently  requires  that  TMantissa  ^  52  when  the  value 
specified  in  a  small  length  clause  is  not  a  power  of  two.  Until  issues  are  resolved  by  the  Ada 
Board  or  AJPO,  the  RIOOO  compiler  does  not  support  small  length  clauses  on  derived  types  that 
specify  a  value  different  from  that  of  the  parent  type. 


4.5.2.  Minimum  Slies  of  Fixed-Point  Types 

There  are  two  equivalent  methods  for  calculating  the  minimum  possible  size  of  a  fixed-point 
type.  Both  are  presented  below  for  completeness. 

Method  1:  The  minimum  possible  size  of  a  fixed-point  type  T  can  be  calculated  using  the  values 
for  the  attributes  ’Mantissa,  'Small,  and  ’Safe.Small,  delink  in  LRM  3.5.9: 

•  If  type  T  has  an  unsigned  range  (that  is,  0.0  S  TFirst  ^  TXasO,  the  minimum  size  of  type  T  is 
TMantissa  *  CrSmall/TSafe.Small).  For  example: 

typ«  T1  Is  dslts  1.0  rang*  0.0  ..  8.0;  —  Tl'Saf«_Saisll  »  Tl' Small 

—  Tl'Mantissa  »  3 

sis*  for  Tl  is  3 

•  If  type  T  has  a  signed  range  (that  is,  TFirst  S  0.0),  the  minimum  size  of  tyj)e  T  is 
TMantissa  *  (TSmall/TSafe_Small)  +  1.  For  example: 

typa  T2  Is  dslta  0.5  eanga  -8.0  ..  8.0;  —  T2'Safs;jSaall  «  T2' Small 

—  T2'llantissa  >  4 

Minimum  sis*  for  T2  is  5 

Method  2:  Becaxise  fbced-point  types  are  represented  as  integers,  the  minimum  possible  size  of  a 
fixed-point  type  can  also  be  computed  using  the  rules  given  in  Section  4.2.2.  Each  fixed-point 
type  T  is  represented  tising  an  integer  subtype  whose  bounds  are  the  integer  representations  of 
the  model-number  bounds  for  type  T  (see  LRM  3.5.9).  The  model-number  bounds  and  their 
integer  representations  are  determined  as  follows: 

•  If  type  T  has  an  unsigned  range  (that  is,  0.0  ^  TFirst  ^  TLast),  the  low  model-number  bound 
is  0.0  and  the  high  model-number  bound  is  -TLarge.  Therefore,  the  integer  representation  of 
type  T  is  as  follows  (assuming  the  integer  conversion  informally  indicated  by  int  has  taken 
place)  and  the  minimum  size  of  type  T  is  the  size  of  this  integer  subtype: 

typ«  I  la  rang*  0  . .  Int  (V’ Laxgm/T' Saf«_Small) ; 
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For  example,  for  type  T1  declared  below,  the  model  numbers  are  multiples  of  1.0 
(Tl’Safe_Small)  in  the  range  0.0  to  7.0  (Tl’Large).  As  shown,  these  values  are  represented 
using  the  integers  in  the  range  0  ..  7,  yielding  an  integer  subtype  whose  minimum  size  is  3: 

typ«  T1  Is  dslts  1.0  rsngs  0.0  ..  8.0;  —  MiniaBim  slzs  for  T1  la  I' Sirs 

typ«  I  Is  rang*  0  ..  7;  —  I'Slss  ■  3 

•  If  type  T  has  a  signed  range  (that  is,  T’First  S  0.0),  the  high  model-number  bound  is  TLarge 
and  the  low  model-number  bound  is  -T’Large.  Therefore,  the  integer  representation  of  type  T 
is  as  follows  (assuming  the  integer  conversions  informally  indicated  by  Int  have  taken  place) 
and  the  minimum  size  of  type  T  is  the  size  of  this  integer  subtype: 

typs  I  Is  ssngs  int  f-T'Lsrge/T' Sa£a_Saiall)  ..  lot  (T' Lsrgs/T' Safe_Siiiall) ; 

For  example,  for  type  T2  declared  below,  the  model  numbers  are  multiples  of  0.5 
(T2’Safe_Small)  in  the  range  -7.5  (-T2’Large)  to  7.5  Cr2’Large).  As  shown,  these  values  are 
represented  using  the  integers  in  the  range  -15  ..  15,  which  yields  an  integer  subtype  whose 
minimum  size  is  5: 

typs  T2  is  dalta  0.5  xanga  -8.0  ..  8.0;  —  Minimum  slza  for  T2  is  I'Slza 

typa  I  is  ranga  -15  ..15;  —  I'Slza  Is  5 


4.5.3.  Sizes  of  Fixed-Point  Types  and  Objects 

In  the  absence  of  a  size  length  clause,  a  fi-xed-point  type  T  is  represented  using  either  the 
minimum  possible  size  or  a  size  that  is  one  bit  larger  than  the  minimum.  The  minimum  possible 
size  is  us^  only  when  it  allows  the  specified  bounds  (TFirst  and  TLast)  to  be  represented. 
However,  as  shown  in  the  previous  section,  the  minimum  possible  size  is  evaluated  using 
model-number  bounds  rather  than  the  specified  bounds.  Because  the  model-number  bound  may 
fall  within  the  specified  bounds  (for  example,  T’large  may  be  slightly  less  than  TLasO,  the 
minimum  possible  size  may  not  be  large  enough  to  allow  the  representation  of  the  specified 
bounds.  In  such  cases,  the  RIOOO  compiler  chooses  a  size  that  is  one  bit  larger  than  the  minimum 
to  accommodate  the  specified  bounds  (that  is,  TLast  $  TSafe_Large).  More  specifically,  the  RIOOO 
compiler  evaluates  the  size  of  a  fixed-point  type  T  by  calculating  the  size  of  an  integer  subtype  of 
the  following  form  (assuming  the  integer  conversions  informally  indicated  by  int  have  taken 
place): 

typ«  Z  !•  ranga  ine  (T'First/T' Sa£e_S]nall)  ..  int  (T' Last/T' 8af a_&nall^ ; 

The  resulting  size  must  be  less  than  or  equal  to  64  bits. 

For  example,  consider  the  type  Tl,  whose  minimum  possible  size  is  3,  as  shown  above.  This 
minimum  size  derives  from  a  representation  based  on  the  model  numbers  0.0  and  7.0  (TLarge). 
However,  this  representation  does  not  include  8.0  (T’Last).  Therefore,  the  RIOOO  compiler  chooses 
a  size  that  is  one  bit  larger  than  the  minimum  and  that  can  include  the  specified  bounds: 

typa  Tl  is  dalta  1 . 0  ranga  0 . 0  .  .  3 . 0  —  Niniaua  slza  Is  3 

—  Tl'Siza  »  4 
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In  contrast,  consider  the  type  T3,  whose  minimum  possible  size  is  also  3.  Because  its 
model-number  bounds  correspond  to  the  specified  boun^,  the  RIOOO  compiler  can  (and  does) 
choose  the  minimum  possible  size  for  T3’Size: 

typ«  T3  is  delta  1.0  range  0.0  ..  7.0  —  siz«  !«  3 

—  T3'Sisa  a  3 

When  an  applicable  size  length  clause  is  present,  a  fixed-point  type  is  represented  using  the 
specified  size.  The  size  specified  in  a  size  length  clause  must  be  greater  than  or  equal  to  the 
minimum  possible  size.  (Thus,  the  specified  size  may  in  some  cases  be  one  bit  smaller  than  the 
size  chosen  by  the  RKXX)  compiler.)  The  specified  size  must  also  be  less  than  or  equal  to  64  bits. 

For  example,  consider  T4,  a  derived  type  whose  parent  type  is  T1  given  above.  Without  the  size 
length  clause,  the  RIOOO  compiler  would  choose  a  representation  of  four  bits;  however,  because  a 
size  length  clause  is  specified,  this  choice  is  overridden  and  the  R10(X)  compiler  is  forced”  to 
represent  type  T4  using  the  minimum  possible  size  of  three  bits: 

typ«  T4  Is  nsw  Tl;  --  Mintmun  sirs  Is  3 

fox  T4'Slz«  us«  3;  —  T4'Slza  «  3 


4.6.  Access  Types 

The  representation  of  access  types  can  be  contrdled  using  size  length  clauses  and  storage-size 
length  clauses.  The  following  sections  describe  the  representation  of  access  types  in  the  absence 
of  these  clauses  as  well  as  the  implementation-dependent  restrictions  using  these  clauses. 


4.6.1.  Representation  of  Access  Types 

For  each  access  type,  a  contiguous  block  of  memory  called  a  collection  is  reserved  to  provide 
storage  for  allocated  objects  of  the  designated  type.  A  collection  for  a  given  access  type  comes 
into  existence  at  the  time  the  access  type’s  dedaration  is  elaborated.  If  insufficient  memory  is 
available  at  the  time  such  a  declaration  is  elaborated,  the  Storage_Error  exception  is  raised. 

Each  object  of  an  access  type  contains  a  value  that  points  to  an  object  of  the  designated  type 
within  the  access  type’s  cdlection.  Each  such  value  is  the  Mr  (the  number  of  bits)  between 
the  beginning  of  the  access  type’s  collection  and  the  beginning  of  the  designated  object.  In  this 
way,  the  RKXX)  compiler  differs  from  many  other  ccxnpilers,  for  which  the  values  of  access  types 
are  represented  as  absolute  machine  addresses. 


4.6.2.  TSlze  and  TStorage.Size 

For  an  access  type  T  of  the  following  form  (where  the  ellipsis  stands  for  the  name  of  the 
designated  type): 

typ«  T  is  «cc«s«  ... 

there  are  two  relevant  measures  of  size*. 
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•  TSize  is  the  number  of  bits  used  to  represent  the  objects  of  access  typ>e  T.  Thus,  TSize  is  the 
number  of  bits  in  which  bit  offset  values  are  represented. 

•  TStorage_Size  is  the  size  (in  bits)  of  the  collection  that  is  reserved  for  T.  Note  that  by 
measuring  the  collection  size  in  bits,  the  RIOOO  compiler  differs  from  many  other  compilers, 
which  measure  collection  size  in  bytes. 

As  described  in  the  LRM,  values  for  T’Size  and  TStorage_Size  can  be  specified  lising  size  length 
clauses  and  storage-size  length  clauses,  respectively.  Whereas  size  length  clauses  specify  the 
precise  size  to  be  used  for  access  objects,  a  storage-size  length  clause  merely  specifies  the 
minimum  size  to  be  used  for  an  access  type’s  collection.  In  fact,  the  RIOOO  compiler  uses  the 
specified  storage-size  value  only  when  this  value  is  a  power  of  two;  otherwise,  the  RIOOO 
compiler  rounds  this  value  up  to  the  next  power  of  two.  For  example: 

typ«  T  la  accasa  _ 

for  T' Storaga_Slza  uaa  1000;  —  T' Storaga_Siz«  »  1024 


4.6.3.  Restrictions  on  Size  and  Storage-Size  Specifications 

If  both  a  size  length  clause  and  a  storage-size  length  clause  are  specified  for  an  access  type  T, 
then  the  values  specified  in  these  clauses  must  satisfy  all  of  the  following  restrictions: 

•  The  value  specified  for  T’Size  is  in  the  range  1  ..  32.  This  value  must  be  static. 

•  The  value  specified  for  T’Storage_Size  is  in  the  range  2  ..  2**.  This  value  may  be  static  or 
dynamic. 

•  The  value  specified  for  TStorage_Size  is  less  than  or  equal  to  2'^*“.  (Thus,  TStorage_Size 
establishes  a  minimum  value  for  TSize:  conversely,  T’Size  establishes  a  maximum  value  for 
TStorage_Size.) 

Failure  to  satisfy  these  restrictions  results  in  ihe  errors  listed  below: 

•  If  the  first  restriction  is  not  satisfied  (that  is,  T’Size  is  out  of  range),  the  size  length  clause  is 
rejected  at  compile  time. 

•  If  the  second  restriction  is  not  satisfied  (that  is,  TStorage_Size  is  out  of  range)  and  the  value 
specified  for  TStorage_Size  is  static,  the  storage-size  length  claxise  is  rejeaed  at  compile  time. 
If,  however,  the  value  of  TStorage_Size  is  both  out  of  range  and  dynamic,  the  Constraint- 
_Error  exception  is  raised  at  run  time. 

•  If  the  third  restriction  is  not  satisfied  and  the  value  specified  for  TStorage_Size  is  static,  then 
the  order  of  the  size  and  storage-size  length  clauses  is  important — the  first  of  the  two  clauses 
is  accepted  and  the  second  clause  is  rejeaed  at  compile  time.  If,  however,  the  value  of 
TStorage_Size  is  dynamic,  the  Storage_Error  exception  is  raised  at  run  time. 

Although  all  values  for  TSize  and  TStorage_Size  are  accepted  if  they  fall  within  the  ranges  given 
above,  certain  small  values  are  not  useful  in  praaice.  In  particular,  if  TSize  ^  7  and  TStorage_Size 
^  128,  the  collection  of  access  type  T  is  too  small  for  objects  of  the  designated  type  to  be 
allocated.  This  is  because  the  RIOOO  compiler  allocates  a  header  of  at  least  128  bits  at  the 
beginning  of  every  collection.  The  header  requires  more  than  128  bits  when  unchecked  deallo¬ 
cation  'is  enabled. 
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Note  that  the  RIOOO  compiler  allows  size  length  davises  to  apply  to  derived  access  types; 
however,  the  size  specified  for  a  derived  type  must  be  the  same  as  the  size  of  its  parent  type. 


4.6.4.  Compiler-Chosen  Representations 

When  neither  a  size  length  dause  nor  a  storage-size  length  dause  applies  to  an  access  type  T,  the 
RIOOO  compiler  chooses  the  following  representation  for  T: 

•  The  value  of  TSize  is  24 

•  The  value  of  TStorage_Size  is  2^* 

When  a  length  dause  is  specified  for  one  of  TSize  or  TStorage_Size  (but  not  both),  the  RIOOO 
compiler  chooses  the  remaining  value  in  accordance  with  the  restrictions  given  above.  Thus: 

•  If  a  size  length  dause  is  specified,  but  a  storage-size  length  dause  is  not,  the  RIOOO  compiler 
sets  T’Storage_Size  *  2'’^“*.  For  example: 

typ«  T  Is  accaas  . . . ; 

for  T'Slxo  usa  20;  —  T' Storaga_Slza  »  2**20 

•  If  a  storage-size  length  clause  is  specified,  but  a  size  length  dause  is  not,  several  cases  must 
be  considered: 

—  If  the  value  specified  for  TStorage_Size  is  s^tic,  then  the  RIOOO  compiler  sets  TSize  » 
flogjTStorage.Sizel.  This  value  is  the  least  integer  that  is  greater  than  or  equal  to 
log2TStorage_Size.  For  example: 

typa  T  la  accaas  . . . ;  —  T' StoragajSlza  »  1024 

for  T' Stozaga_Slza  usa  1000;  —  T'Siza  »  10 

—  If  the  value  specified  for  TStorage_Size  is  dynamic  and  the  storage-size  length  dause 
immediately  follows  the  access-type  dedaration,  then  the  RIOOO  compiler  sets  TSize  - 
r log2TStorage_Sizel  as  before;  now,  however,  this  value  is  computed  at  run  time: 

typa  T  la  accaas  ...;  —  T'Siza  *  calling (log2f  (x) ) 

for  T'  Storaga_Slza  usa  f  (x) ;  coaoputad  at  run  tlma 

—  If  the  value  specified  for  TStorage_Size  is  dynamic  and  the  storage-size  length  dause  does 
not  immediately  follow  the  access-type  dedaration,  then  the  RIOOO  compiler  sets  TSize  - 
24: 

typa  T  la  accaas  ...;  —  T'Siza  a  24 

oCAar  daclarationa 

for  T' Storaga_Slza  usa  f (x) ; 
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4.7.  Task  Types 

Each  object  of  a  task  type  is  associated  with  a  task  control  block  that  contains  all  the  information 
the  system  needs  to  sdiedule  the  task.  A  given  task  object  is  represented  as  the  machine  address 
of  the  task  control  block  associated  with  it.  Because  tasks  are  represented  as  machine  addresses, 
all  task  types,  subtypes,  and  objects  are  the  size  of  System.Address,  which  is  64.  Size  length 
clauses  are  allowed  only  if  they  specify  a  size  of  64. 

In  the  absence  of  an  applicable  storage-size  length  clause,  the  storage-size  for  a  task  type, 
subtype,  or  object  is  23*.  A  storage-size  length  clause  can  be  provided  to  assign  a  different  value 
to  TStorage_Si2e;  however,  such  a  clause  is  primarily  for  compatibility  with  other  compilers  and 
has  no  real  effect  on  the  RIOOO  compiler.  The  value  specified  in  a  storage-size  length  clause  may 
be  static  or  dynamic  and  must  be  in  the  range  0  ..  23*. 

4.8.  Array  Types 

The  elements  of  an  array  are  stored  in  contiguous  memory  locations  with  the  first  array 
component  stored  at  the  lowest  address.  All  components  of  an  array  have  the  same  size,  with  no 
gaps  between  them  (in  essence,  pragma  Pack  is  always  in  effea).  For  example,  one-dimensional 
arrays  of  tyi)e  A1  are  laid  out  as  shown  in  Figure  1; 

typ«  A1  is  array  (1  . .  N)  of  T; 


Figure  t  A  One-Dimensional  Array 


Similarly,  two-dimensional  arrays  of  type  A2  have  the  layout  shown  in  Figure  2; 


typa  A2  Is  array  (1  . .  N, 


1 


M)  of  T; 
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Figure!  A  Two-Dimensional  Array 


4.8.1.  Dope  Vectors 

Every  array  has  associated  with  it  information  about  its  size  and  the  botinds  of  each  of  its 
dimeitsions.  This  information  is  represented  in  the  form  of  a  dope  vector  (sometimes  called  an 
array  descriptor).  For  all  arrays  whose  types  are  constrained  and  for  most  arrays  whose  types  are 
unconstrained,  the  dope  vector  is  stored  as  a  separate  object  associated  with  the  array’s  type  or 
subtype.  When  this  is  the  case,  the  dope  vector  is  an  internal  construct  that  has  no  consequences 
for  the  representation  of  the  array  itself. 

However,  when  an  array  of  an  unconstrained  type  is  used  in  either  of  the  following  two  ways, 
the  array's  dope  vector  is  included  as  part  of  the  array's  representation: 

•  The  array’s  type  is  the  designated  type  of  an  access  type.  For  example: 

typ«  S  is  accass  String;  —  String  Is  an  unconstralnad  array  typ« 

X  :  S  :«  naw  String  (1  ..  17);  —  Allocata  a  string  with  bounds  1..17 

Y  :  S  :»  now  String  <1  ..  36);  —  Allocats  a  string  with  bounds  1..36 

As  shown,  each  of  the  arrays  allocated  in  the  access  type’s  collection  may  have  different 
bounds.  Consequently,  the  dope  veaor  containing  information  about  the  array’s  bounds  must 
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be  stored  with  the  array  itself.  Extra  space  is  allocated  with  each  array  to  accommodate  its 
dope  vector. 

•  The  array  is  a  component  of  a  record  and  is  constrained  by  a  cUscriminant  of  that  record.  For 
example: 

typ«  R  (D  :  Intagvr)  Is 
sscoxd 

r  :  String  (1  . .  O) ;  —  String  Is  an  unconstrslnad  array  type 

end  record; 

X  :  R(17);  —  String  component  with  bounds  1..17 

y  :  R(36);  —  String  conponent  with  bounds  1..36 

As  shown,  each  object  of  type  R  may  have  a  string  component  with  different  bounds. 
Consequently,  the  dope  vector  containing  information  about  the  string  component’s  bounds  is 
stored  with  the  string  itself.  Extra  space  is  allocated  with  each  array  field  to  accommodate  its 
dope  vector. 

The  dope  vector  for  an  array  contains  bounds  and  size  information  for  each  of  its  dimensions.  For 
all  but  the  last  dimension,  this  information  is  represented  in  96-bit  triples.  Thus,  if  an  array  A  has 
N  dimensions,  the  triple  for  a  given  dimension  K  (K  <  N)  contains: 

•  The  value  of  A’First(K),  stored  in  the  first  32  bits  of  the  triple 

•  The  value  of  A’LengthCK),  stored  in  the  second  32  bits  of  the  triple 

•  The  size  (in  bits)  of  the  subarray  formed  by  dimensions  K+1  ..  N,  stored  in  the  remaining  32 
bits  of  the  triple.  The  informal  notation  A  Size(K)  is  used  to  express  this  subarray  size. 

The  last  dimension  is  represented  as  a  64-bit  pair  containing  the  first  two  of  the  three  values  listed 
above  (that  is,  A’First(N)  and  A'Length(.\)).  The  subarray  size  is  omitted  because  the  last 
dimension  defines  no  subarray. 

If  A  is  a  nonnull  array  (an  array  that  contains  at  least  one  element),  its  dope  vector  is  exactly  as 
described  above;  thus  the  size  of  the  dope  vector  for  a  nonnull  array  is  96N  -  32  bits. 

If  A  is  a  null  array  (an  array  that  contains  zero  elements  because  at  least  one  dimension  has  a  null 
range),  its  dope  vector  includes  an  additional  series  of  32-bit  entries  that  contain  the  values  of 
A’Last  for  each  dimension.  Thus,  the  size  of  a  dope  vector  for  a  null  array  is  128N  -  32  bits. 

Figure  3  shows  the  general  dope-vector  layout  for  N-dimensional  nonnull  and  null  arrays: 


28 


September  1990 


RATIONAL 


^pendix  F  for  the  RIOOO  Target 


A'Rrst(l) 

(32  bits) 

ATength(1) 

(32  bits) 

A'Size(1) 

(32  bits) 

• 

A'FlfSt(N-l) 

(32  bits) 

A'Length(N-1) 

(32  bits) 

A'Size(N-1) 

(32  bits) 

A'FlrstfN) 

(32  bits) 

A'Length(N) 

(32  bits) 

Dope  vector  for  nonnult  array 


A'FIrst(1) 

(32  bits) 

ATength(l) 

(32  bits) 

A'Size(1) 

(32  bits) 

A'Rrst(N-1) 

(32  bits) 

A'Length(N-1) 

(32  bits) 

A'SIze(N-1) 

(32  bits) 

A'Rfst(N) 

(32  bits) 

A'Length(N) 

(32  bits) 

A'Last(1) 

(32  bits) 

A'Last(2) 

(32  bits) 

* 

• 

A'Last(N) 

(32  bits) 

Dope  vector  for  null  array 


Figures  General  Dope-Vector  Layout  for  Notmutt  am!  PfttU  Arrays 


For  example,  the  following  declarations  show  that  a  one-dimensional,  nonnull  array  of  type  A3 
has  been  allocated  in  the  collection  of  access  type  PI.  Figure  4  shows  the  array’s  layout: 

typ«  A3  is  array  (Posltlva  rang*  <>)  of  T; 
typ«  PI  Is  accass  A3; 

X  :  PI  :s  naw  A3  (1  . .  N)  ; 
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T 

Dope  vector 


Figure  4  A  One-Dimensional  Array  wUb  a  Dope  Vector 


Similarly,  the  following  declarations  show  that  a  two-dimensional,  nonnull  array  of  type  A4  has 
been  allocated  in  the  collection  of  access  type  P2.  Figure  5  shov.  the  array’s  layout 

type  A4  Is  array  (Positive  range  <>,  Positive  range  <>)  of  T; 
type  P2  Is  access  A4; 
y  :  P2  new  A4  (1  . .  N,  1  . .  M) ; 
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PigttrgS  A  Two-Dimenskmai  Array  wUb  a  Dope  Vector 


4o&2.  Sizes  ofArray  Types  and  Subtypes 

The  size  of  a  constrained  array  type  is  obtained  by  multiplying  the  number  of  components  by  the 
size  of  the  components.  For  example,  the  following  constrained  array  type  Tl  has  10  Boolean 
components,  and  the  size  of  each  component  is  Boolean’Size  -  1.  Therefore,  the  size  of  the  array 
type  Tl  is  lOx  1  -  10: 

typ«  Tl  is  array  (1..10)  of  Boolean;  —  Tl'Sire  ■  10 

Obuining  the  size  of  an  unconstrained  array  type  involves  multiplying  the  maximum  number  of 
components  by  the  size  of  the  components  and  then  adding  to  this  product  the  size  of  the  dope 
vector.  The  dope-vector  size  is  added  because  the  size  of  an  unconstrained  array  type  must  be 
large  enough  to  accommodate  any  array  ol^ect,  induding  one  whose  representation  contains  a 
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dope  vector  (see  Section  4.8.1,  above).  Furthermore,  because  dope-vector  sizes  differ  for  nonnuil 
and  null  arrays,  the  size  of  an  unconstrained  type  must  be  able  to  accommodate  either  kind  of 
array.  Therefore,  the  formula  for  calculating  the  size  of  an  unconstrained  N-dimensional  array 
type  is  given  informally  as: 

Max  (maximum_number_of_components  x  -  component_size,  32N)  +  96n  -  32 

This  formula  ensures  that  the  minimum  size  of  the  unconstrained  array  type  is  32N  +  96N  -  32  - 
128N  -  32,  which  is  the  size  required  for  the  dope  vector  for  a  null  array. 

For  examine,  the  following  unconstrained  array  type  T2  has  a  maximum  of  two  integer  com¬ 
ponents;  ^e  size  of  each  component  is  Integer’Size  -  32.  Because  the  product  2  x  32  is  greater 
than  32N  (which  equals  32  for  a  one-dimensional  array),  the  size  of  T2  is  (2  x  32)  +  (96  x  1)  -  32 
-  128: 

type  T2  Is  szzsy  (Boolssn  range  <>)  of  Integer;  —  T2'Slze  »  128 

Now  consider  the  following  unconstrained  array  type  T3,  which  has  a  maximum  of  two  Boolean 
components,  each  of  size  Boolean’Size  -  1.  Because  the  product  2  x  1  is  less  than  32N  (which 
again  equals  32),  the  size  of  T3  is  32  +  (96  x  1)  -  32  -  96: 

type  T3  Is  array  (Boolean  range  <>)  of  Boolean;  —  TS'Size  «  96 

Note  that  the  size  of  an  array  subtype  is  less  than  or  equal  to  the  size  of  its  base  type.  In 
particular,  a  constrained  subtype  is  smaller  than  its  base  type  if  the  base  type  is  unconstrained. 
This  is  because  the  size  of  the  unconstrained  base  type  is  t^culated  using  the  maximum  possible 
number  of  components  and  also  includes  the  size  of  the  dope  vector.  In  contrast,  the  size  of  the 
constrained  sulxype  is  calculated  using  the  specified  number  of  components  (which  may  be  less 
than  the  maximum)  and  does  not  include  the  size  of  the  dope  vector. 

The  size  of  an  array  type  or  subtype  cannot  be  changed.  Thus,  a  size  length  clause  is  accepted 
only  if  it  specifies  the  size  that  would  normally  be  used  by  the  R1(XX)  compiler. 


4.8.3.  Sizes  of  Arrays 

All  arrays  are  objects  of  some  constrained  subtype  and,  in  most  cases,  are  of  the  same  size  as  that 
subtype.  However,  in  two  cases,  the  size  of  an  array  will  be  larger  than  the  size  of  its  constrained 
subtype — namely,  when  the  array  is  a  designated  object  of  an  access  type  or  when  the  array  is  a 
record  component  that  is  constrained  by  a  discriminant.  In  each  of  these  cases,  a  dope  veaor  is 
included  in  the  representation  of  the  array.  Therefore,  the  size  of  the  array  is  equal  to  the  size  of 
its  subtype  pliis  the  size  of  the  dope  vector.  (Recall  that  the  dope  vector  size  is  96N  -  32  for  an 
N-dimensional  nonnull  array,  and  128N  -  32  for  an  N-dimensional  null  array.) 

For  example,  consider  the  following  declarations,  in  which  the  unconstrained  array  type  String  is 
used  as  the  designated  type  of  an  access  type  S: 

type  S  !•  access  String; 

Z  :  S  :«  new  String  (1  ..  10);  --  Z.all'Slza  «  144 
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The  access  object  Z  allocates  an  array  of  a  constrained  subtype  of  String  with  10  components. 
Because  the  components  are  of  type  Character,  their  size  is  Character’Size  -  8,  so  the  size  of  the 
constrained  subtype  is  10  x  8  -  80.  Because  the  allocated  array  is  one-dimensional  and  nonnull, 
its  dope-vector  size  is  96  -  32  -  64,  so  the  size  of  the  allocated  array  is  80  64  -  144. 


4.9.  Record  Types 

The  representation  of  a  record  type  is  divided  into  fields  corresponding  to  the  record’s  various 
components.  In  the  representations  of  certain  record  types,  the  set  of  component  fields  is 
prefixed  wtth  efther  one  or  two  compiler-generated  fidds.  The  layout  and  sizes  of  record 
representation  fields  are  described  in  following  sections. 


4.9.1.  Layout  of  Helds  Representing  Record  Components 

Record  types  may  have  any  combination  of  several  different  kinds  of  components.  Fixed 
components  refer  to  any  components  that  are  dedared  in  the  fixed  part  of  the  dedaration;  variant 
con^xments  refer  to  any  components  that  are  dedared  in  the  variant  part  of  the  dedaration. 
Furthermore,  a  given  fixed  or  variant  component  is  either  indirect  (an  array  or  record  ^ose 
constraint  is  dependent  on  a  discriminanO  or  direct  (all  other  components).  Discriminants  are  the 
components  on  which  the  values  of  other  components  may  depend. 

The  fields  that  represent  a  record  type’s  components  are  arranged  by  component  kind  and  occur 
in  the  following  order,  with  no  gaps  between  them  (in  essence,  pragma  Pack  is  always  in  effecO: 

•  Fields  for  discriminants 

•  Fields  for  fixed  components  (within  the  fixed  part,  fidds  for  direct  components  precede  fields 
for  indirect  components) 

•  Fields  for  variant  components  (within  each  variant  of  the  variant  part,  fields  for  direct 
components  precede  the  fidds  for  indirect  components) 

Where  there  are  multiple  components  of  a  given  kirxl  (for  example,  multiple  discriminants  or 
fixed  direct  components),  the  (xder  of  their  fields  is  taken  from  the  Ada  source  code. 

A  record  whose  type  or  subtype  contaiiu  a  variant  part  can  have  exactly  one  active  variant  at  a 
time,  where  an  active  variant  is  the  particular  variant  that  is  sdected  by  the  current  value  of  the 
discriminant.  Accordingly,  the  representation  of  a  variant  record  with  a  given  discriminant  value 
contains  fields  for  only  one  variant  (namely,  the  active  varianO.  The  active  variant’s  fields 
immediatdy  follow  the  fields  for  the  record’s  fixed  components.  Thus,  when  two  variant  reccM’ds 
of  the  same  type  have  different  discriminants,  the  representations  of  these  records  are  identical  up 
to  the  fields  for  the  active  variant  components. 
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Because  the  value  of  an  indirect  component  depends  on  the  value  of  the  discriminant,  the  size  of 
the  indirect  component's  value  may  differ  from  one  record  to  another.  Therefore,  an  indirect 
component  is  represented  using  cwo  separate  fields.  The  first  fidd  (called  an  indirect  pointer  field 
is  a  64-bit  pointer  to  the  second  field  (called  a  data  field),  which  contains  the  actual  value  of  the 
component  The  indirect  pointer  field  consists  of: 

•  A  32-bit  offset,  which  is  the  integer  number  of  bits  from  the  beginning  of  the  record  and  the 
data  field 

•  A  32-bit  integer  expressing  the  size  of  the  data  field 

Within  a  given  record,  the  data  fields  for  ail  indirect  components  (both  fixed  and  variant)  occur  at 
the  end  of  the  record,  following  the  representation  of  the  active  variant  (if  any). 


4.9.2.  Layout  of  Compiler-Generated  Fields 

For  discriminated  record  types  (including  variant  record  types),  the  compiler  generates  the  first 
field  in  the  representation.  'Ihis  field  consists  of  a  single  bit  called  the  constrained  object  bit.  The 
constrained  object  bit,  which  corresponds  to  the  'Constrained  attribute,  is  used  as  part  of  the 
memory-protection  scheme  of  the  RIOOO  architecture.  The  constrained  object  bit  precedes  the 
fields  for  the  user-defined  components. 

For  variant  record  types  with  a  nonempty  variant  part,  the  compiler  generates  an  additional  field 
that  follows  the  constrained  object  bit.  This  second  field  consists  of  an  8-bit  variant  clause  index 
(VQ),  which  is  used  for  fast  discriminant  checking  whenever  a  component  in  a  variant  is 
referenced.  That  is,  within  a  given  variant  record  type  R,  each  variant  in  the  variant  part  is 
implicitly  assigned  a  number,  starting  with  1.  (The  variants  are  numbered  sequentially  in  the  order 
in  which  they  appear  in  the  type's  declaration.)  When  a  particular  record  of  type  R  selects  an 
active  variant,  the  number  assigned  to  that  variant  is  then  stored  in  the  record’s  VCI  field. 

If  a  variant  itself  contains  a  nonempty  variant  part,  then  the  variant  is  represented  as  an 
anonymous  record,  prefixed  with  its  own  constrained  object  bit  and  VCI  field. 


4.9.3.  Examples  of  Record  Layout 

Assume  that  type  R1  is  a  record  type  containing  only  fixed  direa  components: 

typ«  R1  Is 
record 

ri  :  Integer; 

W2  :  Boolean; 
r3  :  String  (1  . .  10) ; 
end  record; 

Then  a  record  of  type  Rl  has  the  representation  shown  in  Figure  6  (note  that  the  size  of  each 
field  is  determined  by  the  component  subtype): 


—  fixed  direct  coo^nent 

—  fixed  direct  coiqponent 

—  fixed  direct  component 
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Figure  6  A  Record  wUb  Fixed  Direct  Components 


Assume  that  type  R2  is  a  discriminated  record  type  with  one  fixed  direct  component  and  two 
fixed  indirect  components: 

typ«  82  (O  :  Integer)  is  —  dlscrininant  coaponent 


sscosd 

ri 

Intsgsr; 

— -  find  dinct  cotaponent 

V2 

String  (1 

..  D); 

—  flmd  indiract  component 

ra 

String  (1 

..  D); 

— >  £iaced  indirect  component 

#4 

Boolnan; 

—  fixed  direct  component 

•nd  sseord; 

Then  a  record  of  type  R2  has  the  representation  shown  in  Figure  7.  As  shown,  the  representation 
of  R2  has  a  constrained  object  bit,  followed  by  the  fields  for  the  discriminant  D  and  the  direct 
components  FI  and  F4,  followed  by  pointer  and  data  fields  for  the  indirect  components  F2  and 
F3.  Note  that  the  sizes  of  the  discriminant  held  and  the  direct  fields  are  determined  by  the 
component  subtypes,  whereas  the  sizes  of  the  data  fields  depend  on  the  discriminant  value. 
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R2'Constrained  (1  bit) 


D  (32  bits) 


FI  (32  bits) 


F4  (1  bit) 


F2'Offset  (32  bits) 


F2‘Size  (32  bits) 


F3'Offset  (32  bits) 


F3'Size  (32  bits) 


F2  data 


F3  data 


Figure  7  A  Record  with  Direct  and  Indirect  Components 


Assume  that  type  R3  is  a  variant  record  type  with  one  discriminant,  one  fixed  direct  component, 
and  a  variant  part  containing  two  variants.  These  variants,  which  each  contain  a  single  direct 
component,  are  assigned  VCI  numbers  1  and  2: 

type  R3  (D  :  Boolaam)  Is 
record 

ri  :  Integer; 
ease  D  Is 

when  True  «> 

r2  :  Integer; 
when  raise  >> 
r3  :  Float; 
end  case; 
end  record; 

Depending  on  the  value  of  the  discriminant,  a  record  of  type  R3  has  either  of  the  representations 
shown  in  Figure  8.  Both  representations  begin  with  the  constrained  object  bit  and  a  VCI  field, 
followed  by  the  fields  for  the  discriminant  D  and  the  fixed  direa  component  FI.  When  the 


—  dlscrijalnant  coo^nant 

—  fixed  direct  conponent 
“  VCI  Is  1 

—  variant  direct  cos^nent 

—  VCI  is  2 

—  variant  direct  coo^nent 
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record’s  discriminant  is  True,  the  representation  on  the  left  is  used,  in  which  the  VQ  is  1  and  the 
active  variant  is  one  containing  the  Integer  component  When  the  record's  discriminant  is  False, 
the  representation  <mi  the  right  is  used,  in  which  the  VQ  is  2  and  the  active  variant  is  one 
containing  the  Float  component 


Active  variant 

Jl 


RS'CofUtrained  (1  bit) 


VO  >  1  (8  bits) 


0(1  bit) 


n  (32  bits) 


F2  (32  bits) 


When  0  s  True 


R3'G)nstrained  (1  blQ 


Va-2(8bits) 


D  (1  bit) 


FI  (32  bits) 


F3  (64  biU) 


I 


Active  variant 


When  0  »  False 

PtgurmS  A  Record  tvitb  Fixed  and  Variant  Components 


4.9.4.  Sizes  of  Record  Types  and  Subtypes 

In  general,  the  size  of  a  record  type  is  the  sum  oS  the  sizes  of  the  fields  that  represent  its 
components  plus  the  sizes  of  any  compiler-generated  fields.  For  a  variant  record  type,  the  sum 
includes  the  size  of  the  active  variant  if  the  discriminant  is  constrained;  otherwise,  the  size  of  the 
largest  variant  is  used.  The  following  paragraphs  discuss  in  more  detail  how  sizes  are  calculated 
for  particular  kinds  of  record  types.  (Table  4,  in  Section  4.9.6,  summarizes  the  sizes  for  the 
various  kinds  of  fields.) 

1.  Nonvariant  Record  Types:  Nonvariant  record  types  have  a  fixed  part  but  no  variant  part.  The 
sizes  of  such  types  are  affected  by  whether  or  not  there  is  a  discriminant: 

a.  A  nonvariant  record  type  with  no  discriminant  has  only  fixed  direct  components. 
Therefore,  the  size  of  the  type  is  simply  the  sum  of  the  sizes  of  all  of  the  component 
subtypes.  For  examjirfe,  the  size  of  type  R1  (presented  in  Section  4.9.3,  above)  is  the  sum 
of  the  sizes  of  Integer,  Boolean,  and  a  string  with  10  characters. 

b.  A  nonvariant  record  type  with  a  discriminant  may  have  both  fixed  direct  and  fixed  indirect 
components.  Therefore,  the  size  of  the  type  is  the  sum  of  the  sizes  of  the  component 
subtypes  plus  the  size  of  the  constrained  object  bit  (1  biO  plus  the  sizes  of  any  indirect 
field  pointers  (64  bits  per  pointer).  Recall  from  Section  4.8  that  if  any  component  contains 
a  discriminant-dependent  array,  the  size  of  that  component  subtype  must  contain  the  size 
of  the  array’s  dope  vector. 
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2.  Variant  Record  types:  Variant  record  types  have  both  a  discriminant  and  a  variant  part.  The 
sizes  of  such  types  are  aHected  by  whether  or  not  the  discriminant  is  constrained  (a  con¬ 
strained  discriminant  has  a  specific  value,  which  selects  an  active  variant): 

a.  A  variant  record  with  a  constrained  discriminant  has  exactly  one  active  variant  in  addition 
to  zero  or  more  fixed  direct  and  indirect  components.  Therefore,  the  size  of  the  type  is 
the  size  of  its  fixed  part  (as  given  in  item  lb  above)  plus  the  size  of  the  VCI  field  (8  bits) 
plus  the  size  of  the  active  variant  The  size  of  the  active  variant  is,  in  turn,  the  sum  of  the 
sizes  of  its  component  subtypes  and  their  dope  vectors  (if  any),  plus  any  indirect  pointers, 
plus  (if  the  variant  contains  a  nested  variant  part)  the  size  of  the  nested  active  variant, 
including  its  VQ  field  and  constrained  objea  bit. 

b.  A  variant  record  with  an  unconstrained  discriminant  has  multiple  variants,  each  of  which 
is  a  candidate  for  selection  as  the  active  variant  Therefore,  the  size  of  the  type  is  the  size 
of  its  fixed  part  (as  given  in  item  lb  above)  plus  the  size  of  the  VQ  field  (8  bits)  plus  the 
size  of  the  largest  variant.  (Thus,  you  must  evaluate  the  size  of  each  variant  and  use  the 
maximum  of  these  sizes.)  The  size  of  a  variant  is  the  sum  of  the  sizes  of  its  component 
subtypes  and  their  dope  vectors  (if  any),  plus  any  indirect  pointers,  plus  (if  the  variant 
contains  a  nested  variant  part)  the  size  of  the  largest  nested  variant,  including  its  va  field 
and  constrained  object  bit. 

The  RIOOO  compiler  chooses  the  minimum  size  for  a  record  type,  given  the  record  layout 
described  above.  The  size  of  a  record  type  cannot  be  increased  using  a  size  length  clause.  A  size 
length  clause  is  accepted  only  if  it  specifies  the  compiler-chosen  size  for  the  type. 


4.9.5.  Sizes  of  Record  Objects 

The  size  of  a  record  objea  is  the  size  of  its  subtype. 


4.9.6.  Summary  of  Record  Field  Sizes 

Table  4  summarizes  the  sizes  of  computer-generated  fields  as  well  as  fields  that  represent  various 
kinds  of  components. 


Table  4  Summary  of  Record  Field  Sizes 


Field 

Size 

Constrained  objea  bit 

1  bit 

Variant  clause  index  (VCI) 

8  bits 

Discriminant 

Size  of  component  subtype 

Direa  component 

Size  of  component  subtype 

Indirea  component  (record) 

64  bits  for  pointer  size  of  component  subtype 

Indirea  component  (array) 

64  bits  for  pointer  +  size  of  component  subtype 
(inciuding  dope-vector  size) 
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4.9.7.  Record  Representation  Clauses 

Record  representation  clauses  may  be  used  to  force  a  different  field  order,  to  introduce  gaps 
between  fields,  or  to  alter  the  size  a  field.  However  the  following  restrictions  must  be 
observed: 

•  The  compiler-generated  fields  (constrained  object  bit  and  VO),  if  present,  cannot  be  moved 
from  their  normal  positions  at  the  be^nning  of  the  record. 

•  The  discriminant  fields  may  not  be  reordered,  nor  may  gaps  be  introduced  between 
discriminants.  The  size  of  a  discriminant  may  be  changed. 

•  If  the  field  order  is  changed  from  the  default,  the  fields  must  still  be  ordered  by  component 
kind: 

—  Discriminant 

—  Fixed  components  (direct  preceding  indirect) 

—  Variant  components  (direct  preceding  indirect  within  each  variant) 

•  The  size  of  fields  for  components  of  subtype  array,  record,  access,  or  task  cannot  be  changed 
from  their  default  values.  The  size  of  other  fields  must  follow  the  rules  for  size  length  clauses 
for  those  types. 

•  The  placement  of  indirect  field  pointers  and  indirect  data  fields  carmot  be  specified  xjsing  a 
record  representation  clause. 

•  The  constraints  on  the  component  subtype,  if  any,  must  be  static. 

5.  IMPLEMENTATION-GENERATED  NAMES 

No  implementation-generated  names  are  used  by  the  RIOOO  compiler. 

6.  ADDRESS  CLAUSES 

The  RIOOO  compiler  uses  a  memory-protection  scheme  that  prohibits  arbitrary  address  computa¬ 
tions  including  the  use  of  an  address  literal.  For  this  reason,  the  type  System.Address  is  a  private 
type  and  no  conversion  functions  are  provided  to  convert  other  v^ues  to  System.Address.  Conse¬ 
quently,  address  clauses  are  not  supported  by  the  RIOOO  compiler. 

6.1.  Address  Clauses  for  Interrupt  Entries 

Because  interrupts  do  not  exist  in  the  RIOOO  architecture,  address  claxises  for  interrupt  entries  are 
not  needed  and  thus  are  not  supported. 


7.  UNCHECKED  PROGRAMMING 
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7.1.  Unchecked_Conversion  Function 

The  Unchecked_Conversion  generic  function  converts  objects  of  one  type  to  objects  of  another 
type.  Its  formal  parameter  list  is: 

g^erlc 

typ«  Sourctt  Is  llaltsd  private; 
type  Target  Is  limited  private; 
function  Unchecke^Conversion  (S  :  Source)  return  Target; 

where  Source  specifies  the  original  type  of  the  object  to  be  converted  and  Target  specifies  the 
type  that  will  result  from  the  conversion.  More  specifically,  ^en  a  source  object  S  is  converted, 
its  bit  pattern  (binary  representation)  is  converted  to  the  bit  pattern  of  the  Target  type. 

The  source  and  target  bit  patterns  are  left-justified.  Thus,  the  leftmost  bit  of  the  source  object 
becomes  the  leftmost  bit  of  the  target  object.  If  the  source  object  is  smaller  than  the  target  object, 
the  target  object  will  contain  an  undefined  pattern  in  the  bit  positions  not  filled  by  the  source.  If 
the  source  object  is  larger  than  the  target  object,  then  the  rightmost  bits  of  the  source  object  are 
ignored. 

Unchecked  conversion  from  a  Source  to  a  Target  type  yields  unpredictable  results  and  therefore 
is  not  recommended  if: 

•  Either  type  is  or  contains  an  unconstrained  array  type 

•  Either  type  is  or  contains  a  discriminated  record 

This  is  because  the  bit  patterns  of  unconstrained  array  types  and  discriminated  records  contain 
compiler-generated  fieldis  such  as  dope  vectors  (see  Section  4.8.1)  and  constrained  object  bits, 
variant  clause  indexes,  or  indirect  field  pointers  (see  Section  4.9).  Conversion  from  one  of  these 
types  may  cause  the  target  data  to  contain  unexpected  bits.  Conversion  to  one  of  these  types  may 
cause  bits  from  the  source  object  to  be  mapped  into  bit  positions  in  the  target  that  are  reserved 
for  compiler-generated  fields,  possibly  causing  these  fields  to  contain  illegal  values.  When  this 
happens,  an  exception  such  as  System.Type_Error,  System.Capability_Error,  or  System.Assertion- 
_Error  is  raised  at  run  time.  Note  that  conversions  involving  constrained  array  subtypes  or  records 
without  discriminants  produce  reliable  results. 

A  faster  alternative  to  the  Unchecked_Conversion  function  is  package  Unchecked_Conversions. 
For  additional  information  and  examples,  see  the  reference  entries  for  the  Unchecked_Conversion 
function  and  package  Unchecked_Conversions  in  the  Programming  Tools  (PD  book  of  the 
Rational  Environment  Reference  Manual 

7.2.  Unchecked_Deallocation  Procedure 

The  Unchecked_Deallocation  procedure  may  be  instantiated  for  any  access  type.  Its  purpose  is  to 
deallocate  storage  for  the  designated  objects,  so  that  the  storage  can  be  reclaimed  and  reused. 
This  procedure  can  reclaim  storage  for  an  access  type  only  if  deallocation  has  already  been 
enabled  in  either  of  the  following  ways: 

•  The  user  has  included  pragma  Enable_Deallocation  for  the  access  type,  or 
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•  The  applicable  library  switch  R1000_Cg.Enable_Deallocation  had  the  value  True  when  the 
program  was  compiled,  and  there  is  no  pragma  Disable.Deallocation  for  the  access  type. 

The  formal  parameter  list  of  the  Unchecked_Deallocation  procedure  is: 

gwMrle 

typ«  Object  Is  limited  private; 
type  Hame  is  access  Object; 
procedure  UacheckedJDeallocation  (X  :  in  out  Name) ; 

If  deallocation  has  been  enabled  for  the  access  type  in  question,  the  Unchecked.Deallocation 
procedure  first  reclaims  the  storage  for  the  objea  designated  by  the  pointer  X  and  then  assigns 
null  to  X.  If  deallocation  has  not  been  enabled  for  the  access  type,  then  storage  is  not  reclaimed, 
although  X  is  still  set  to  null.  Fuithermore,  even  if  deallocation  is  eiubled,  storage  is  reclaimed 
only  if  it  is  safe.  For  example,  if  an  access  type  has  a  designated  type  that  is  or  contains  a  task, 
the  RIOOO  architecture  prevents  storage  reclamation  for  that  access  type  because  such  reclamation 
could  jeopardize  system  integrity.  In  these  situations,  X  is  set  to  null  even  though  storage  is  not 
reclaimed.  Note  that  the  rules  for  determining  whether  it  is  safe  to  reclaim  storage  are  complex. 
The  user  can  determine  whether  storage  reclamation  is  possible  through  an  instantiation  of  the 
generic  function  Allows_Deallocation. 

Enabling  deallocation  for  an  access  type  T  causes  each  allocated  object  to  consume  additional 
space  (specifically,  twice  TSize)  within  the  collection.  In  the  absence  of  size  length  clauses  or 
storage-size  length  clauses,  TSize  is  24  bits;  consequently,  each  allocated  object  typically 
consumes  an  additional  48  bits  of  the  collection.  This  additional  space  is  used  for  a  free  list, 
which  serves  to  keep  track  of  the  portions  of  the  collection  that  are  in  tjse.  Furthermore,  enabling 
deallocation  increases  the  size  of  the  collection  header,  causing  it  to  be  greater  than  128.  Thus, 
enabling  deallocation  has  the  effect  of  decreasing  the  maximum  number  of  objects  that  can  be 
allocated  in  a  colleaion.  For  this  reason,  deallocation  is  normally  left  disabled  in  a  library  and 
enabled  only  when  needed,  either  on  a  library-by-library  basis  (with  the  R1000_Cg.Enable_Deal- 
location  switch)  or  on  a  type-by-type  basis  (with  pragma  Enable.Oeallocation). 

For  additional  information,  see  the  reference  entries  for  the  Allows_Deallocation  fiinaion  and  the 
Unchecked.Deallocation  procedure  in  the  Programming  Tools  (PT)  book  of  the  Rational 
Environment  Reference  Manual 


8.  INPUr/OUTPUr  PACKAGES 

The  Environment  supports  all  of  the  I/O  packages  defined  in  Chapter  14  of  the  LRM,  except  for 
package  Low_LeveLlo,  which  is  not  needed.  The  Environment  al^  provides  a  number  of  other 
I/O  packages.  The  packages  defined  in  Chapter  14,  as  well  as  the  other  I/O  packages  supported 
by  the  Environment,  are  more  fully  documented  in  the  Text  Input/Output  (TO)  and  Data  and 
Device  Input/Output  (DIO)  books  of  the  Rational  Environment  Reference  Manual  The  following 
subsections  summarize  the  implementation-dependent  features  of  the  Chapter  14  I/O  packages. 
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8.1.  Filenames 

Filenames  must  conform  to  the  syntax  of  Ada  identifiers.  They  can,  however,  be  keywords  of  the 
Ada  language. 

8.2.  Form  Parameter 

The  Open  and  Create  procedures  in  packages  Text_Io  and  lo  each  have  a  Form  parameter  for 
controlling  the  way  in  which  files,  terminals,  and  Ada  units  are  read.  Form  parameters  are  similar 
to  Options  parameters  in  other  Environment  commands  and  can  be  specified  using  the  same 
syntax.  The  particular  form  options  that  are  available  depend  on  what  is  being  read. 

The  following  form  option  is  available  when  reading  Ada  units: 

•  Pag«_Px«gina_Mapplng 

A  Boolean  option.  Sprecifies  whether  instances  of  pragma  Page  cause  an  ASCII.FF  to  be 
inserted  at  the  end  of  the  line  to  force  a  page  break.  The  default  is  False. 
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The  following  form  options  are  available  for  terminal-specific  I/O: 

•  Crl£ 

A  Boolean  option.  Specifies  whether  ASCn.LF  should  be  mapped  to  the  combination  ASCn.CR 
and  ASCn.LF.  The  default  is  True. 

•  Echo 

A  Boolean  option.  Specifies  whether  to  echo  input  The  default  is  True. 

•  Kditing«/f<em/ 

Specifies  whether  line  editing  is  in  effect  The  literal  value  Line  causes  line  editing  to  be  in 
effect  The  literal  value  None  disables  line  editing.  The  default  value  is  Line. 

For  text  files: 

•  6at«way 

A  Boolean  option.  Specifies  whether  a  file  is  to  be  read  as  a  gateway  file  (a  category  of 
remote  files  that  are  accessed  through  specific  Rational  layered  products).  The  default  is  False. 

•  Synehxonlz«d 

A  Boolean  option.  Specifies  whether  the  read  operation  requires  a  complete  and  consistent 
copy  of  the  file.  When  False,  unsynchronized  access  is  permitted,  so  that  files  can  be  read 
even  if  they  are  open  for  editing  or  are  being  written  by  an  active  program.  When  True,  files 
can  be  read  only  if  they  are  closed.  The  default  is  False. 


8.3*  Instantiations  of  Packages  Direct.Io  and  Sequential_Io 

Instantiations  of  packages  Direct_Io  and  Sequential_Io  with  access  types  are  permitted.  However, 
if  files  are  created  or  opened  using  such  instantiations,  the  Use.Error  exception  is  raised. 


8.4.  Count  Type 

The  Count  type  for  package  Text_Io  and  package  Directjo  is  defined  as: 
packaga  Taxt_Xo  Is 

typa  Count  Is  ranga  0  . .  1_000_000_000; 

and  Taxt_Io; 

packaga  Dlract_Io  Is 

typa  Count  is  naw  Intagax 

zanga  0  . .  Intagaz'  Last/KlaaiantJTypa'  Siza; 


and  Dlzact  Xo; 
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8.5*  Field  Subtype 

The  Field  subtype  for  package  Text_Io  is  defined  as; 

subtype  Flald  la  Integer  range  0  ..  Integer' Last; 


8.6.  Standard_Input  and  Standard_Output  Files 

when  a  job  is  run  from  a  command  window,  these  files  are  the  interactive  input/output  windows 
provided  by  the  Rational  editor.  When  a  job  is  run  from  package  Program,  options  allow  the  user 
to  specify  what  Standardjnput  and  Standard_Output  will  be. 


8.7.  Internal  and  External  Files 

More  than  one  internal  file  can  be  associated  with  a  single  external  file  for  input  only.  Only  one 
internal  file  can  be  associated  with  a  single  external  file  for  output  or  in-out  operations. 


8.8.  Sequential.Io  and  Direct.Io  Packages 

Package  Sequential_Io  can  be  instantiated  for  unconstrained  array  types  or  for  types  with 
discriminants  without  default  discriminant  values.  Package  Direct_Io  cannot  be  instantiated  for 
unconstrained  array  types  or  for  types  with  discriminants  without  default  discriminant  values. 

8.9.  Terminators 

The  line  terminator  is  denoted  by  the  character  ASCII.LF,  the  page  terminator  is  denoted  by  the 
character  ASCII.FF,  and  the  end-of-file  terminator  is  implicit  at  the  end  of  the  file.  A  line 
terminator  directly  followed  by  a  page  terminator  is  compressed  to  the  single  character  ASQI.FF. 
The  line  and  page  termirutors  preceding  the  file  termirutor  are  implicit  and  do  not  appear  as 
characters  in  the  file.  For  the  sake  of  portability,  programs  should  not  depend  on  this 
representation,  although  it  can  be  necessary  to  use  this  representation  when  importing  source 
files  from  another  environment  or  exporting  source  from  the  Rational  Environment. 


8.10.  Treatment  of  Control  Characters 

Control  characters,  other  than  the  terminators  described  above,  are  passed  directly  to  and  from 
files  to  application  programs. 


8.11.  Concurrent  Properties 

The  Chapter  14  I/O  packages  assume  that  concurrent  requests  for  I/O  resources  are  synchronized 
by  the  application  program  making  the  requests,  except  for  package  Textjo,  which  synchronizes 
requests  for  output. 
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9.  CAPACITY  RESTRICTIONS 

The  following  package  specifies  the  absolute  limits  on  the  use  of  certain  language  features; 


with  System; 
peckage  Tiimits  Is 

—  Scanner 
llax_Line_Length 


—  Semantics 

Manjlscrtmi  nants__In_Constralnt 

Kax_Assoclatlons__Xn_Recoxd_Aggregat« 

Max_rielda_Zn_Recoxd_Aggregate 

Ma3cjrozaals_In_Generlc 

HaxJsestedjContezts 

Kax  Ohlts  In  With  Lists 


—  Code  Generator 
NaxJParaffleters_In_Call 
jlax_MUBiber__0£_Flelds_In_A__Record 
]lax__llumber_0£_Bntrles_In^A_Task 
Kax_NumborjO£JDlmanslons_In_An_Array 
MaxJSestlngjOf  Subprograms  Or_Blocka_InjiJPaekaqe_Or__Task 

:  constant  :>  14; 


constant 

:■ 

254; 

constant 

:■ 

256 

constant 

:* 

256 

constant 

:■ 

256 

constant 

:» 

256 

constant 

:■ 

250 

constant 

;■ 

256 

constant 

•  s 

255; 

constant 

255; 

constant 

:■ 

255; 

constant 

63; 

MaxjObject^Slse 
end  Limits; 


;  coutant  :*  (2**32)  *Systam. Bit; 


10.  ATTRIBlJrES  OF  NUMERIC  TYPES 

This  section  lists  the  values  returned  by  attributes  that  apply  to  integer  types,  floating-point  types, 
and  the  fixed-point  type  EXiration. 


10.1.  Integer  Types 

The  attributes  that  apply  to  integer  types — namely,  ’First,  ’last,  and  ’Size — ^yield  the  values  shown 


below  for  the  two  predefined  base  types. 

Values  for  type  Integer: 

Attribute 

Value 

First 

-2**31+1 

Last 

2**31-1 

Slsa 

32 
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Values  for  type  Long_Integer; 


Attribute 

Value 

First 

-2**63 

Last 

2**63-l 

Slsa 

64 

10.2.  Floating-Point  Types 

The  attributes  that  apply  to  floating-point  types  yield  the  following  values  for  the  predefined  base 
type  Float: 


Attribute 

Digits 

■psllon 

risat 

Lasgs 

L*at 

Mschlnsjpasx 

Mschlns^Cnain 

Machin«_Kantl8SS 

Wachi  tis_pvrf  lows 

MacM  nsjadiat 

KachlasMRounds 

Mantissa 

Safa_BBax 

Sa£a_^Lasg« 

Sa£a_Small 

Slsa 

Small 


Value 

IS 

204 

8 . 881784197001251-16 

-1 . 79769313486231B-I-308 

2.57110087081438K+61 

1 . 79769313486231B4-308 

1024 

-1073 

53 

Trua 

2 

Falsa 

51 

1024 

Float' Last  -  5. 98752092860416K-I-292 
2.0** (-1025) 

64 

1 . 94469227433161K-62 


10.3.  Type  Duration 

The  attributes  that  apply  to  fixed-point  types  yield  the  following  values  for  the  predefined  type 
Duration: 
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Attribute 

Aft 

Delta 

First 

Worm 

XiMxgm 

Last 

Mantissa 

Safa_Larga 

Sa£a__SBall 

Sisa 

Small 

Maehl najOvarf lows 
Marh* Rounds 


Value 

5 

3.051757812SS-05 

-4.294967296S-f0» 

11 

4.29496729(1409 

4.2949672961409 

47 

2 . 814749767106561414 
3.05175781251-05 

48 

3.05175781251-05 

Tsua 

Falsa 
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